feat(extension): channel-flip guard for the chat session DB

[aarontrowbridge]

Motivation

2026-08-08 fleet incident: the extension update refreshed the vendored opencode binary, swapping a dev-channel build for a local-channel one. opencode picks its chat DB by build channel (dev → opencode-dev.db, unbranded/local → opencode-local.db), so launchd restarted a healthy server on a fresh, empty database — every fleet panel showed an empty history while the 650-session opencode-dev.db sat untouched on disk. Diagnosis required reading minified bundle strings; total silent-failure window was hours.

What this does

Two never-blocking additions to ServerManager:

1. Provenance log line — the spawned binary's sha256 goes to the output channel at start, so the next post-mortem starts with "which binary was it" already answered (complements feat(extension): build provenance stamping for verifiable binaries #292's provenance stamping).
2. warnIfServingFreshDb — after the health probe, if /session?limit=1000 serves < 10 sessions while a sibling opencode-*.db on disk exceeds 32 MB, the extension appends a WARNING and toasts with an "Open Output" action. The silent-empty-panel symptom becomes an explicit, actionable error.

False-positive analysis

• Fresh install → no large sibling DB → silent.
• A fork serving its own large DB → high session count → silent.
• Client riding the SSH tunnel → serves the canonical count through the tunnel → silent (the disk scan runs client-side, but the count check gates first).
• Any probe failure → silent by construction (fire-and-forget, .catch(() => {})).

Validation

• tsc --noEmit clean.
• vitest: 905 passed; the 3 failures in test/server_auth.test.ts (buildServerSpawnEnv key-exactness) reproduce identically on unmodified main (0944b3b) — pre-existing, unrelated. Worth its own issue.

Follow-ups (not in this PR)

• Server-side boot banner (channel, resolved DB path, session count) — belongs in the opencode fork, not the extension.
• Attach-only client mode (Client machines silently fork the chat DB: extension always spawns a local server (needs attach-only mode) #279) remains the structural fix for the fork family.
• Machine-local hardening (wrapper-side OPENCODE_DB pin, frozen server binary, 5-min watchdog) already applied to the fleet server.