Project sandbox failure diagnostics into durable D1 observations

[evilstar9527]

Summary

When a publisher or execution sandbox process fails, its container is reaped on the terminal observation, so /v1/executions/{id}/logs returns an empty fallback. The Worker already computed a diagnostic from stderr, but only logged it to short-retention Workers Logs — never to the durable, queryable executor_observations.facts_json. Net effect: an exit-1 failure left no recoverable cause (the blocker-8/10 observability gap).

This projects the failure cause into D1 so it survives container reaping.

Changes

• sandboxProcessDiagnostic now also classifies:
  • publisher failures — the plain delivery publisher failed: <code>:<step> line (step validated against the publisher runner's error codes)
  • execution failures — the execution_attempt_result / failed structured log (reusing the analysis failureKind/failureStage vocabulary)
  • (existing analysis + bootstrap cases unchanged)
• CloudflareSandboxProviderFact carries two optional flat strings diagnosticKind + diagnosticDetail (bounded), added to both .strict() provider-fact schemas (worker-emit + control-plane-parse) and threaded through the runtime client's parse+reconstruct.
• On a failed observation the Worker sets these from the diagnostic (compact JSON detail), or — when unclassified — keeps a bounded raw stderr tail so an exit-1 still leaves a clue. The plugin copies them into ExecutionFact.facts, which persists to executor_observations.facts_json.

Tested

• 963 unit + 550 workflow pass; tsc --noEmit + eslint . clean.
• New parser cases (publisher with/without step, unknown step dropped, execution failure) in the worker test; runtime-client test asserts the fields survive the strict parse; plugin test asserts a failed observation surfaces the diagnostic into facts.
• Validated in prod (v22): a real tipsy-backend work execution failed (exit 1); executor_observations.facts_json now records {"exitCode":"1","diagnosticKind":"execution_failure","diagnosticDetail":"{\"kind\":\"execution_failure\"}"} — recovered after the container was reaped (raw /logs was empty, as expected).

Scope

Observability only. No change to publisher logic, the watchdog, or retry behavior. The container is still reaped on terminal (no sandbox leak); the cause now survives in D1.

Known follow-up (not in this PR)

The prod validation surfaced a deeper gap: the execution_failure diagnostic had no failureKind/failureStage — the execution runner emitted the failed result without a classified ExecutionAttemptError.kind. So we now know which lane failed, not yet why. That's a runner-side classification gap, addressed separately.

🤖 Generated with Claude Code