Stop retrying unavailable thread subscriptions

[tim-smart]

Summary

Subscribing to a deleted (or archived) thread's detail stream previously retried every 250 ms forever — up to the state's 5-minute idle TTL per dead thread — flooding the WebSocket RPC log with Thread … was not found errors (~4/sec per thread).

• OrchestrationGetSnapshotError gains an optional reason: thread-deleted / thread-archived / thread-missing (optional keeps it wire-compatible in both directions).
• The server's subscribeThread handler distinguishes the cases via a new ProjectionSnapshotQuery.getThreadLifecycleById that reads the projection row without the deleted/archived filters.
• The client treats thread-deleted as terminal (marks the thread deleted, purges the cache, stops resubscribing) and thread-archived as terminal-with-cached-data. thread-missing keeps the 250 ms retry so the subscribe-before-projection race on freshly created threads still converges.

Testing

• 3 new client tests in threads-sync.test.ts (deleted → terminal + state deleted, archived → terminal + cache kept, missing → retries)
• 2 new server WS tests for the reason discrimination, plus a real-SQL test for the lifecycle query
• Full runs: server.test.ts, ProjectionSnapshotQuery.test.ts, client-runtime package, repo typecheck + lint — all green on top of t3code/worktree-remove-confirmation

🤖 Generated with Claude Code

[tim-smart]

Duplicate of #17 — that PR is now retargeted onto t3code/worktree-remove-confirmation for the stack.