operator: triage the ambient fleet scan off-context, escalate only findings

[edwin-zvs]

Follow-up to #369/#371. Addresses the context-accumulation problem with the ambient loop.

Problem

The ambient loop runs in the operator's own session, and #371 made each tick rich (fleet snapshot + up to 10 PTY-screen previews). Those got push_msg!'d into the operator's persistent conversation, so:

• every tick — and every real user turn — ran near the budget ceiling on a frontier model,
• stale per-tick snapshots (obsolete by the next tick) crowded out the real conversation and drove compaction,
• zarvis.jsonl grew between compactions.

Per the design discussion: the snapshot/previews are throwaway, and continuity is already handled elsewhere (the delta is adapter state; widgets persist on disk). So the bulk shouldn't live in the operator's context at all.

Change: scan → cheap triage → escalate only findings

Each tick now runs a one-shot monitor triage — a separate completion, ideally on a cheaper model — that judges the data-only snapshot + previews off the operator's context and returns a concise finding or nothing:

• Quiet tick → nothing → the loop continues; the operator is never touched.
• A finding → a compact, evidenced observation (a sentence per flagged session + a snippet + the session id) becomes the operator turn. The operator never sees the raw previews — it can drill in itself with the id if it wants.

AGENTD_OPERATOR_MONITOR_MODEL selects the monitor model (falls back to the operator's). The triage is stateless and bounded, so its cost doesn't grow over time and is cheap with a small model. The monitor triages mechanically (no user-context); the operator filters with context.

Pieces

• build_ambient_observation now yields a data-only scan (judgment instructions moved to AMBIENT_MONITOR_SYSTEM); snapshot summary trimmed accordingly.
• run_ambient_triage (one-shot complete, no tools, discard sink) + parse_triage_finding (reply → compact observation or None).
• AmbientTick arm: scan → triage → finding | continue 'outer.

Verification

• parse_triage_finding unit-tested (filters nothing/empty; formats findings); 36 interactive tests pass; full build clean.
• One live triage against the running fleet returned 3 evidenced findings — including a session blocked on a risky-command approval ("? approve [risky] shell(git add … && git push … && gh pr create …)") and one finished with a release outcome — i.e. the compact findings the operator would see, not the previews. On a quiet fleet it returns nothing and the operator isn't woken.

Spec 0022 added. Code in agentd-adapter-zarvis.

Relationship to 40ec9f6 ("Run Operator ambient loop only while fleet active")

That commit landed on main after this branch was first pushed; this PR is now rebased on top of it. They are complementary, not conflicting (clean rebase, builds, tests pass):

• 40ec9f6 controls when a tick fires — only while the fleet is active — and drops the interval from 300s to 60s.
• This PR controls what reaches the operator (only findings) and the per-tick cost (a cheap off-context triage instead of a full operator turn).

Notably, 40ec9f6 alone made the operator run a full frontier turn every 60s while the fleet is active — i.e. the exact context-accumulation / cost problem this PR fixes, made ~5× more frequent by the faster interval. So this PR matters more now. With the 60s cadence, configuring AGENTD_OPERATOR_MONITOR_MODEL to a cheap model is recommended. (Minor: the active-gate and the scan each list() the fleet once per fired tick — a redundant call that could be folded together in a follow-up.)