[Fix] Address v0.6 release feedback

[mrubens]

Summary

• preserve the v0.5 physical database contract during the v0.6 rollback window, including an idempotent repair for databases that already applied the original migrations
• add an upgrade-CI schema contract check that rejects removed or tightened N-1 tables and columns
• scope preview auto-resume detection to the same task and notify parent runs when dequeue/bootstrap cancellation bypasses normal run finalization
• bound cost analytics queries in SQL and replace parameter-heavy PR attribution with a relational join
• recover OpenCode follow-ups after canceling initial session creation
• keep new environments unverified while preserving verification and snapshots for metadata-only edits
• make Discord cancellation terminate the sandbox

Root cause and impact

Several v0.6 changes relied on identifiers or lifecycle assumptions that were safe for the new application but not for a rolling upgrade or rollback. In particular, the candidate migrations renamed a table and removed columns still selected by v0.5. Other paths overloaded sourceRunId, bypassed normal settlement hooks, or treated metadata changes as runtime changes.

This keeps the release compatible with the supported N-1 rollback target and closes the runtime, analytics, environment, OpenCode, and Discord regressions identified during review.

Validation

• pnpm lint:fast
• pnpm check-types:fast
• pnpm knip
• bash -n deploy/ci/upgrade-compatibility.sh
• migration journal consistency test
• fresh migration chain through migration 0016 against PostgreSQL
• simulated already-migrated v0.6 schema followed by the repair migration
• focused Vitest coverage for preview resume, Discord cancellation, OpenCode recovery, dequeue settlement notification, environment verification/snapshot preservation, and legacy/generalized usage persistence
• repository pre-push checks

[roomote-roomote]

No new code issues found. See task

• High — deploy/ci/upgrade-compatibility.sh:221-226: The new contract check requires every table from the develop baseline to retain its name, but that baseline already has migration 0011 applied with the table named llm_usage_events. Drizzle skips the rewritten 0011 by migration timestamp, then 0016 renames that table to task_inference_usage_events, so this query reports missing previous table: llm_usage_events and the upgrade-compatibility job fails. It also means the still-running baseline code can query a relation that no longer exists; preserve a compatible alias/name or adjust the rollout and contract check together.

_{Reviewed 8542c2c}