fix(server): a thread with an unknown event type can still be resynced after a downgrade

[shivamhwp]

If someone runs an older build after a newer one, the database can contain a thread event whose type the older build doesn't know. The server still starts, and opening the thread fresh still works. But any client resuming that thread from a cached position before that event, which is common for mobile and for web after sleep, gets "Could not synchronize the thread." and never recovers until a full reload. Every retry replays from the same position and fails the same way.

Client replay (loadReplayThrough in ws.ts) now skips a row whose event type this build doesn't recognize and logs one warning with the thread, the sequence and the type's length (no raw values, per the repo's logging convention). Everything else stays strict: appends, the provider ingestor, projection writes and every other reader still reject unknown types, and a known type with a broken payload still fails. That's the same line #13941 drew on the client side, where the server stays strict about what it accepts.

The live tail resumes from highWater, which is computed separately from the replay, so skipping a row can't skip real work. If the skipped row is the last one, the client's cursor stays just below it, so a later resubscribe skips it again. That repeat is cheap and harmless.

Reproduced first against the real EventStoreV2 and ProjectionMaintenanceV2 code, simulating a realistic downgrade with the row written and the projection cursor advanced past it:

• server boot: fine
• fresh open: fine
• resubscribe from before the row: fails every time, with no retry

The new tests replay across an unknown row in the middle and at the end, and check that a known type with a broken payload still fails. Without the fix, the replay test fails with PersistenceDecodeError.

Related: #8896 (part 2).

Model: Claude Sonnet 5 and Claude Opus 5.5 (Claude Code)

🤖 Generated with Claude Code

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ No successful main baseline artifact is available yet. This run establishes the initial measurement.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	—	4.9 KiB	—	6.8 KiB	✅
Codex	Thread snapshot wire	—	3.7 KiB	—	4.9 KiB	✅
Codex	Live turn WebSocket wire	—	1.2 KiB	—	2.0 KiB	✅
Codex	Live turn WebSocket decoded	—	20.4 KiB	—	29.3 KiB	✅
Codex	Live turn messages	—	2	—	8	✅
Claude	Total thread wire	—	4.9 KiB	—	6.8 KiB	✅
Claude	Thread snapshot wire	—	3.7 KiB	—	4.9 KiB	✅
Claude	Live turn WebSocket wire	—	1.2 KiB	—	2.0 KiB	✅
Claude	Live turn WebSocket decoded	—	20.8 KiB	—	29.3 KiB	✅
Claude	Live turn messages	—	2	—	8	✅

Baseline: unavailable · PR result: 16e4ef2 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 106.1 KiB
• Claude decoded thread snapshot: 106.4 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The specified range contains a very large cross-product change set, including orchestration rewrites, new provider and scheduled-task capabilities, authentication/authorization changes, and deployment configuration changes. The focused unknown-event replay fix is therefore not sufficiently isolated for automatic approval.

Not approved because:

• Per-review cost limit exceeded (workspace setting). Approvability relies on correctness review in order to determine eligibility

^{Review your spending limits in Billing settings, or comment @macroscope-app review this PR to bypass the limit and review now. You can add or adjust custom eligibility rules. Learn more.}

Dismissing prior approval to re-evaluate 16e4ef2

Dismissing prior approval to re-evaluate 16e4ef2

[macroscopeapp]

Macroscope skipped reviewing this pull request. Per-review cost limit exceeded (workspace setting).

This review would cost an estimated $15.26, which exceeds your per-review limit of $15.00.

The top 3 files driving up this estimate:

File	Diff Size	Estimate
packages/contracts/src/orchestrationV2.ts	127.32KB	$2.09
apps/server/src/mcp/OrchestratorMcpService.ts	75.70KB	$1.24
apps/server/src/orchestration-v2/EventSink.ts	33.91KB	$0.56

Tip

To get this pull request reviewed, you can:

1. Comment @macroscope-app on this PR to request a manual review (monthly spend limits still apply).
2. Exclude the file(s) above from review by adding a pattern to your .macroscope/ignore.md — note that creating this file replaces Macroscope's built-in default ignores rather than extending them.
3. Raise your cost limit in your workspace billing settings.

^{Turn off this reminder going forward}

[shivamhwp]

Closing: this targeted the v2 branch, which is now merged and deleted. The bug still reproduces on main, so it's refiled as #15937.