feat(controller): add typed runtime failure reasons

[OnlyTerp]

Summary

• Adds a shared RuntimeFailureReason type.
• Attaches optional reason/code metadata to launch/switch results and launch-progress SSE payloads while preserving raw message/detail strings.
• Introduces a focused launch failure classifier for common local runtime failures.
• Surfaces typed reasons in /launch/:recipeId and chat-proxy 503 errors where available.
• Rebased onto current main; adapted the frontend launch-progress type/equality changes to the current consolidated files.

Verification

• bun test tests/controller/integration/launch-failure-classifier.test.ts tests/controller/integration/observability-contracts.test.ts — 16 pass, 0 fail
• npm --prefix controller run typecheck
• npm --prefix controller run lint

Known upstream check

• npm run check:contracts currently fails on current main with duplicate AggregatedSession exports in frontend/src/app/api/agent/sessions/all/route.ts and frontend/src/features/agent/session-contracts.ts; this PR does not touch those files.

Notes

• No DB migrations or recipe schema changes.
• No UI redesign, crash-loop budget, readiness panel, or auto-launch behavior.
• New reason/code fields are optional; existing raw error strings remain intact for compatibility.

[OnlyTerp]

Rebuilt from scratch on current main: RuntimeFailureReason contract (16 values, registered in validate-shared-contracts), a conservative classifier with 11 tests, and reason/code threaded through LaunchResult → waitForReady → setActiveRecipe/ensureActive → publishLaunchProgress → LaunchProgressData (with equality comparison). Scope deliberately excludes HttpStatus — the Effect v4 TaggedErrorClass migration made that a separate conversation. Crash-loop-blocked launches carry code "crash-loop-blocked". check:quality green on push.

[0xSero]

The concept still holds up post-launch-failure-budget — the budget says how often a launch fails, this says why, and the optional fields keep it backward-compatible. But main has moved ~240 commits: engine-service.ts was deleted (SetActiveRecipeResult now lives in engine-coordinator.ts), and five other files conflict, so this needs a rebase (~1-2h, mostly type relocation). On the rebase, two asks: tighten hasVramOom — bare "vram" matches benign startup VRAM-usage lines in the 3000-byte tail, so many ordinary crashes would misclassify as vram_oom — and either type the code values or drop them in favor of reason (also "unknown" is in the union but never emitted).