fix(collab): preview install-hang watchdog + crash-loop breaker + cache telemetry

[hblanken]

Part of the stability hardening pass (PR 1 of 5). Targets the frontend's heavy install/compile path on the 4 vCPU / 16 GB task.

S1 — install-hang watchdog

The 30-min idle cap only counts request traffic, so a pnpm install wedged at minute 5 (dead registry, stuck native build, OOMing dep) held memory for 25 more minutes before anything noticed. Now: track _lastOutput per active state (reset on every stdout/stderr line); the existing 60-s sweep stops any preview still in the installing phase that has emitted nothing for 5 min. A healthy install/compile emits progress constantly, so prolonged silence is a strong wedge signal.

S2 — crash-loop breaker on auto-resume

The 24-h freshness cap (PR #32) stops stale intents from looping, but a fresh intent whose workspace is deterministically broken re-crashed on every boot. New collab_session columns preview_crash_count + preview_crash_at:

• Incremented when a preview's child exits non-zero while still installing (and when the watchdog kills a hung install)
• Reset to 0 on a successful install→running transition
• Boot-resume skips any session with ≥ 3 install crashes in the last hour
• A Driver pressing Launch clears the counter (explicit human retry overrides the breaker)

Only install-phase crashes feed the counter — a crash after reaching "running" is a dev-server runtime error, a different class that shouldn't suppress resume (the workspace installed fine).

V2 — framework-cache telemetry

Logs whether <repo>/.angular/cache survived the previous container at each launch. That cache lives on EFS and should persist across deploys; when it does, second-launch compile drops from ~2 min to ~20 s. If it logs "absent" on a previously-launched session, the cache is being wiped — a regression to chase. Shallow, bounded, never throws.

Schema

Two columns added via the existing PRAGMA-probe ALTER pattern in migrate.ts + the Drizzle table in schema.sql.ts. Legacy rows backfill to crash_count=0 (eligible for resume), so no special handling.

Files

• preview-launcher.ts — _lastOutput tracking, watchdog in sweep, crash record/clear on exit/ready, breaker filter in resume, cache telemetry
• session.ts — recordPreviewCrash / clearPreviewCrashCount helpers, listPreviewIntents carries crash fields
• migrate.ts + schema.sql.ts — new columns
• router.ts — clear crash count on manual launch

Test plan

• Deploy off this branch
• Launch frontend preview → boot log shows framework-cache present/absent line
• Simulate a hung install (point a session at a repo with an unreachable git dep) → after 5 min: install hung — no output for 5m, preview stops, task stays healthy
• Force 3 install crashes on one session → 4th boot logs crash-loop breaker (…) and skips resume; Driver Launch still works (clears counter)
• Healthy preview reaching "running" → crash count resets (verify a later transient install failure starts from 1, not 4)
• No regression: existing launch / stop / idle-cap / lifetime-cap / memory-cap behavior unchanged

🤖 Generated with Claude Code