fix(extension): hub-client file clicks die silently — the open-file handler's no-posture branch needs a named outcome + the runtime wiring of linkResolution needs a bridge-level test #1845

Important

Problem — Live-reported during the v0.3.8-alpha exercise (Aaron, on the macbook/erlich hub-client posture): clicking files in session output (the edit/write tool parts' rows, and some review rows) does nothing — no open, no toast, no console error. Three sibling bugs were found and fixed along the way (#1839 the layout gate, #1841 the diffCanRender gate, #1843 the webview string-frame stream bug + the whole-row click target — all merged, all live on the dist). But the core symptom persists in the last tested state: a verified-rendered <button data-slot="message-part-title-filename" data-clickable> (devtools-probed in the correct iframe context, so the part HAS a path) still produces nothing on click.
The chain, statically verified end-to-end: iframe onClick → openFileInEditor (posts {source:"amicode", kind:"open-file", url:"file://…"} to the parent) → the top-document relay (origin-pinned to the app origin, open-file in the allowlist) → vscode.postMessage → chat_bridge's open-file handler → resolveChatFileLink → Preview. Every link exists in source. The failure is runtime.
Prime suspect — the handler's own documented silent branch (chat_bridge.ts, the if (!linkResolution) path): "without the context the pre-#1826 local-stat gate stands" — if (!fs.existsSync(fsPath)) return true — a hub path on the client's disk fails the stat and returns with NO named outcome. On the hub-client posture that's exactly the observed behavior: total silence. That would mean io.linkResolution is undefined in the live panel's io despite the activation wiring (extension.ts:1209 registers the callback; chat_panel.ts:252 reads it at io construction) — the #1826 slice's unit tests covered the handler logic but never the runtime wiring of the context into the panel io.
Approach — Two fixes: (1) the silent branch becomes a NAMED OUTCOME — the handler must never die silently (the same discipline as the block system's named outcomes: a toast naming "no posture context" or "not found locally (pre-posture gate)"); (2) root-cause the runtime wiring: verify ChatPanel.linkResolutionContextCallback?.() is non-undefined in a real panel's io at click time, and add a BRIDGE-LEVEL test (the panel io construction with the callback registered), not just unit tests over the resolver. If the context is genuinely absent at runtime, find where the registration's activation ordering loses it (stale panel instance? per-message io rebuild? the deck variant?).
Scope — in: chat_bridge's silent branch, the io wiring + its bridge-level test. out: the app-side fixes (already landed: #1839/#1841/#1843 + the row-click target).
Assumptions — Last tested state: extension v0.3.8-alpha.3, dist bundle index-D2RIBKJy.js, amicode.hubServerUrl armed (the P4 telemetry assert passes), posture should be hub-client.