[Feat] Durable diagnostic run events

[daniel-lxs]

PR 1 of the observability pair (PR 2, the OpenCode exit certificate, stacks on this). Motivation: sandbox logs die with the sandbox and Modal exposes none at all, so the last two incident investigations ended at "leading suspect" instead of proof.

What

A diagnostic rail on the existing task_run_events audit table — no schema change:

• diagnostic added to runEventTypes; workers write through the existing sdk.taskRuns.recordEvent path.
• Worker-side recorder (apps/worker/src/run-task/diagnostic-events.ts).
• tasks.runEvents web tRPC reader (mirrors tasks.messageEnvelopes auth) so per-task events are queryable without DB access.

Nothing emits yet — the first producer (OpenCode death certificate) is the follow-up PR, kept separate so this rail can be reviewed on its own.

Guarantees (per the requirements)

• Performance: nothing on hot paths. Recording happens only when a producer calls it (rare lifecycle moments); it's one fire-and-forget API call using the same client workers already hold.
• Behavior: observer-only. The recorder never throws into the caller (build errors and persistence failures are caught and logged), so no task control flow can change.
• Privacy: every string is capped (2k message / 4k detail values, bounded depth) and secret-scrubbed before leaving the process — provider key prefixes (sk-/ghp_/xox…), bearer headers, JWTs, long hex/base64 runs, and *_PASSWORD=/*_TOKEN= style assignments are redacted (tests cover each). Events land in the same org-scoped DB that already stores full task transcripts, behind the same auth.

Tests

6 new tests: scrubber coverage (keys, JWTs, assignments incl. prefixed names, plain-text passthrough), capped+scrubbed recording, never-throws on persistence failure and on cyclic details. Typecheck clean across types/sdk/worker/web; knip clean.

Not auto-merged — ready for review.

🤖 Generated with Claude Code

[roomote-roomote]

Reviewed this PR. The diagnostic rail is well-scoped, observer-only, and the never-throw / scrubbing guarantees are backed by tests. 3 non-blocking things to consider (1 medium, 2 low). See task

• apps/web/src/trpc/commands/tasks/run-events.ts:22-24 (medium) — The reader orders asc(createdAt) then limit(500), so on tasks with more than 500 run events it returns the oldest 500 and silently drops the newest. Since this rail exists for post-mortems and the interesting diagnostics (failures, exit certificates) happen at the end of a run, the reader can drop exactly the events it was built to surface. Consider ordering desc with the limit (reversing client-side for display) or paginating.
• apps/worker/src/run-task/diagnostic-events.ts:100-106 (low) — details is built as { kind: input.kind, ...sanitizedDetails }, so a caller-supplied details.kind silently overrides the recorder's own kind. Spread first and set kind last (or namespace it) so the recorder's classification always wins.
• apps/worker/src/run-task/diagnostic-events.ts:33-34 (low) — The \b[A-Fa-f0-9]{40,}\b and [A-Za-z0-9+/]{48,} patterns will redact non-secret post-mortem evidence such as 40-char git SHAs and sha256 digests. Over-redaction is the safe direction, but it does blunt the debugging value the rail is meant to provide; consider narrowing these token-shaped rules or exempting known hash-length values.