feat(netproxy,diagnose): record network prompts nobody answered in time

[Retr0MrWave]

Issue: Closes #257 · Refs #241

What

• New net.prompt_abandoned audit event for a network prompt that was raised but never resolved.
• Prompt-sourced net.decision events now carry waited_ms — how long the dialog was open before it was answered.
• omac diagnose reports both, and no longer claims "Nothing was blocked by the network policy" for a run where either happened.

Why

While a prompt is open the connection is held, and the requesting tool is subject to its own timeout. The opencode Skainet plugin aborts model discovery after 3s; answering a GUI dialog measurably takes longer (5s measured here, with the dialog already in focus). So the tool gives up, the fetch fails silently, and the allow you then grant applies to a request nobody is waiting for.

Both halves of that were invisible:

• If the run ends with the dialog still open, no net.decision is ever written. omac diagnose reported 0/1 connection(s) blocked · Nothing was blocked by the network policy for a run that had silently failed.
• If the dialog is answered, just too late, a perfectly ordinary allow is recorded and nothing looks wrong at all.

This is not an edge case: the compiled-in default profile (internal/sandboxprofile/resolve.go:23) has no allow_domain, so on a fresh install every host prompts on first contact.

How

• The dialog deliberately runs on a detached context (internal/netprompt/prompt.go:312 builds its timeout from context.Background()), so an open prompt outlives the request that raised it and dies with the process. Detection therefore belongs at teardown: Filter.DrainAbandonedPrompts records whatever is still in flight when the proxy closes. It runs last in Server.Close, after the listener and connections are gone — draining earlier clears the coalescing map while requests can still arrive, which would raise a second dialog for a host already being asked about.
• Nothing in the proxy can observe the requester leaving (clientSourceCtx is also context.Background()-derived), so for the answered-too-late case the prompt's open duration is recorded on the decision instead, and diagnose flags anything ≥3s (promptLatencyThresholdMS — the shortest client budget observed in the wild).
• A prompt already recorded as abandoned does not also emit a decision: promptWait carries a drained flag so one request cannot appear as both abandoned and allowed.
• Abandoned entries are aggregated per host:port with a repeat count and capped at 8, mirroring maxBlockedShown — otherwise --run all emits one line per occurrence across the whole persistent log.

Verification

go build ./..., go vet ./internal/... clean. go test ./internal/netproxy/ -race clean. go test ./... passes except TestIntegrationWorktreeKnownLimitations and TestIntegrationWorkflowInterpretersRunnable, which fail identically on clean main on this host (local toolchain paths absent from the default profile).

Drain path, end to end, no human interaction (the client times out on its own):

omac sandbox run --profile <prompt-enabled> --audit-log /tmp/a.jsonl \
  -- curl -s --max-time 1 https://example.com          # exit 28

diag:  net ABANDONED example.com:443 (prompt raised 967ms ago, no verdict —
       the requesting tool stopped waiting)
audit: net.prompt_abandoned example.com 443 waited_ms=967
omac diagnose:
       last run · filtered mode · 0/0 connection(s) blocked · 1 prompt(s) abandoned
       • 1 network prompt(s) … were raised but never answered in time

Late-answer path (the case the first commit missed — a waited_ms=5200 prompt-sourced allow):

• 1 prompt(s) were answered after 3.0s or more — a short-timeout tool may have failed anyway
  chat.model.tngtech.com:443 was held for 5.2s before the prompt was answered.
  Fix: add these hosts to network.allow_domain so no prompt is raised.

…and no "Nothing was blocked" in either case. Runs with neither condition are unchanged (regression test asserts the note still fires).

The second commit is review fixes; the late-answer detection, the Close ordering, the double-report suppression and the detail cap each have a test.

Follow-up

• Correction to Network prompt latency silently defeats short client timeouts, and an abandoned prompt leaves no record #257 as filed: the issue implies a cancelled request context. The dialog is actually detached and dies with the process, so detection had to move to teardown plus a recorded wait. Worth a comment on the issue.
• Deliberately not included (Network prompt latency silently defeats short client timeouts, and an abandoned prompt leaves no record #257 checklist item 4): making a bare omac sandbox run write the central audit trail. It only gets an auditor when the parent passes --audit-log (internal/sandboxrun/run.go:144), and wiring it would couple sandboxrun to launcher-config loading — worth its own change.

🤖 Generated with Claude Code

[mwtng]

I just rebased and reran the verification. I did not do a review, yet.

But probably one should have a look at the changes to the documentation and if they are really necessary in such detail.