Taking this one. I've reproduced the failure mechanism from the code and have a fix in progress.
What I verified
- The crash path is
ProviderRuntimeRecoveryService.reconcileat startup: it lists recovery-visited threads and decodes each thread'spayload_jsonthroughOrchestrationV2AppThreadJson.settledOverrideonly accepts"settled" | "active" | null, so one row storing a JSON boolean fails decode, the error escapes as a fatalProviderRuntimeRecoveryError, and the server exits code=1 — on every launch, and on 0.1.5 too, since the schema is identical there. No duplicate issue; #16441 is a different read path (turn start). - On the writer: every writer in the current code and the full git history emits literals, encode-side validation rejects booleans, and the event tables never carried one — consistent with your row check. The repo has documented precedent that older/foreign builds share and write the same database (see 900652d817, "sweep index follows payloads written by any build", and #15948's repair migration), so the boolean most plausibly came from a build outside this history.
The fix direction
Make settledOverride decode leniently in the contracts schema, following the existing posture for stored payloads written by any build (LenientThreadOpens, ForwardCompatibleNullable): true decodes as "settled", false as null. Encode stays strict, so the next write of the thread normalizes the stored value back to a literal — no manual database edit needed. This heals reads everywhere the schema is shared: startup recovery, sidebar lists, and the client thread shells.