ai(observability): runChatGrounding and the runCodingAgentAttempt driver path emit no $ai_* telemetry

[JSONbored]

Part of epic #8286 (Phase 3 — AI observability). Follow-up to #10198.

Problem

Two AMS Agent-SDK surfaces make real model calls and emit no $ai_* telemetry at all, so their spend, latency and failure rate are invisible in PostHog.

1. runChatGrounding — never instrumented

packages/loopover-engine/src/miner/chat-grounding.ts drives a full query() session (up to CHAT_MAX_TURNS) with MCP tools attached, and folds the stream into wire events. Nothing on that path captures a generation. A failure becomes a chat_grounding_failed wire event and a provider-config problem becomes an error event — neither reaches PostHog.

Note this driver does not currently surface a usage/result frame at all, so instrumenting it also means folding the SDK's result message (its usage and total_cost_usd) rather than only the assistant/user messages it reads today.

2. runCodingAgentAttempt bypasses the capture wrapper

withCodingAgentAiGenerationCapture is applied inside constructProductionCodingAgentDriver (packages/loopover-miner/lib/coding-agent-construction.ts). The runCodingAgentAttempt path calls createCodingAgentDriver directly (packages/loopover-engine/src/miner/driver-factory.ts), so it never passes through that construction site and every attempt it runs is uncaptured.

That placement is why the bypass is silent: the wrapper is attached at one of two construction sites, and the other one is a plain factory call that looks complete on its own.

Deliverables

• Instrument runChatGrounding with an $ai_generation capture carrying real model/provider/latency, and tokens + cost from the SDK's result frame.
• Ensure every coding-agent attempt is captured regardless of which construction path built the driver — preferably so that a future third call site cannot silently opt out again, rather than by adding the wrapper at a second site.
• Cover the failure paths, not just the happy path: a chat-grounding provider-config error and an SDK throw should both be visible.
• Keep the metadata-only policy — no prompt, transcript or tool output on any event.

[linear-code]

JSO-7123

[JSONbored]

Correction: both surfaces are latent, not live

Verified across the repo — neither surface has a production caller. Both are reachable only from tests and from @loopover/engine's public export surface:

• runChatGrounding — callers: packages/loopover-engine/test/chat-grounding.test.ts only. No reference from src/**, apps/**, packages/loopover-miner/lib/**, or packages/loopover-miner/bin/**.
• runCodingAgentAttempt — callers: packages/loopover-engine/test/driver-factory.test.ts, test/unit/coding-agent-miner.test.ts, and the coding-agent-house-rules.ts composable. That module's own header already says it plainly: "no production caller today -- it's a lower-level composable for a hypothetical caller that wants the non-iterate-loop path", and packages/loopover-miner/docs/coding-agent-driver.md describes it the same way.

The live AMS path is constructProductionCodingAgentDriver → IterateLoopDeps.driver → the iterate loop, and that path is instrumented — withCodingAgentAiGenerationCapture is applied at that construction site, and #10199 landed the real token split through it.

What this changes

The issue as filed overstated the impact. Instrumenting either surface today would add telemetry to code nothing calls in production, and would not fill PostHog's Tools column, because no traffic flows through them. The ORB's own review CLIs are invoked with --tools "" (every built-in tool removed, --strict-mcp-config, mcp__* denied), so they genuinely have no tools to report — an empty Tools column is the truthful reading for the current deployment, not a gap.

Revised scope

This stays open as a correctness-of-contract item rather than an observability outage:

• Instrument both surfaces when a production caller lands, so the instrumentation arrives with the traffic rather than ahead of it.
• runChatGrounding additionally needs the SDK result frame folded in (it reads only assistant/user messages today, so it has no usage or cost to report even if a capture were added) — that work is real regardless of caller.
• The runCodingAgentAttempt bypass is best fixed by injection rather than a second wrapper site: the engine cannot import posthog-node (documented boundary), so a caller-supplied decorator applied only to drivers the factory itself constructs would keep a future third construction site from silently opting out.

Downgrading rather than closing: the bypass is a real structural hazard the moment that path is used, and it is worth fixing before then, not after.