fix(server): bound orchestration replay payloads

[rcawston]

What Changed

• Add a lightweight replay-range query that counts events and serialized payload bytes without decoding them.
• Fall back to a fresh snapshot when a reconnect gap exceeds the existing row limit or an 8 MiB payload budget.
• Apply the same preflight behavior to thread and shell subscriptions.
• Add focused coverage for oversized replay gaps and snapshot fallback behavior.

Why

Severity: high (regular-use blocker).

WebSocket catch-up checked only the number of missing events, then loaded and decoded the entire replay range before deciding whether it was safe to send. A small number of events can contain very large tool payloads, so reconnecting a client to a busy conversation could allocate multiple gigabytes, exhaust V8, restart the backend, and leave the client repeatedly reconnecting without a usable conversation.

Measuring the serialized range first lets the server choose the existing snapshot path before materializing unsafe payloads.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Note

Bound WebSocket orchestration replay payloads to 8 MiB and add getEventReplayStats

• Adds getEventReplayStats to the ProjectionSnapshotQuery service contract and SQL implementation, returning event count and serialized payload bytes for an exclusive-lower/inclusive-upper sequence range without decoding payloads.
• Adds canReplayPersistedRange in ws.ts that rejects ranges ahead of the authoritative head, exceeding the event-gap limit, or exceeding the new 8 MiB serialized-payload budget.
• Shell and thread subscription resume paths now call this helper before reading/decoding events; rejected ranges emit a fresh snapshot followed by synchronized/live updates.
• Risk: subscriptions whose persisted ranges now exceed the 8 MiB budget or head/limit checks will silently switch from replay to snapshot delivery instead of replaying events — reviewers should check canReplayPersistedRange in ws.ts and the getEventReplayStats query in ProjectionSnapshotQuery.ts for boundary correctness.

^{Macroscope summarized adb6780.}

---

Note

Medium Risk
Changes WebSocket reconnect/catch-up behavior for shell and thread subscriptions; incorrect byte accounting could still allow heavy replay or over-snapshot clients, but the path is defensive and well-tested.

Overview
WebSocket subscribeShell and subscribeThread catch-up used to allow replay whenever the sequence gap was within the existing ~1,000-event cap, which could still decode huge tool payloads and OOM the server.

This PR adds getEventReplayStats on ProjectionSnapshotQuery, aggregating event count and serialized payload_json size in SQL via octet_length (no payload decode). canReplayPersistedRange in ws.ts requires both the gap limit and an 8 MiB payload budget (ORCHESTRATION_REPLAY_PAYLOAD_BUDGET_BYTES); otherwise the client gets snapshot + synchronized instead of replay. Test mocks are updated, plus coverage for byte measurement (including emoji) and subscription fallback when stats exceed the budget.

^{Reviewed by Cursor Bugbot for commit adb6780. Bugbot is set up for automated code reviews on this repo. Configure here.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This changes production WebSocket reconnect behavior by adding an always-on 8 MiB policy that can replace event replay with snapshot delivery and introduces a new persistence query used by both shell and thread subscriptions. The focused tests reduce risk, but the autonomous gate and its customer-visible fallback behavior warrant human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[rcawston]

What Changed

• Add a lightweight replay-range query that counts events and serialized payload bytes without decoding them.
• Fall back to a fresh snapshot when a reconnect gap exceeds the existing row limit or an 8 MiB payload budget.
• Apply the same preflight behavior to thread and shell subscriptions.
• Add focused coverage for oversized replay gaps and snapshot fallback behavior.

Why

Severity: high (regular-use blocker).

WebSocket catch-up checked only the number of missing events, then loaded and decoded the entire replay range before deciding whether it was safe to send. A small number of events can contain very large tool payloads, so reconnecting a client to a busy conversation could allocate multiple gigabytes, exhaust V8, restart the backend, and leave the client repeatedly reconnecting without a usable conversation.

Measuring the serialized range first lets the server choose the existing snapshot path before materializing unsafe payloads.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Note

Bound WebSocket orchestration replay payloads to 8 MiB and add getEventReplayStats

• Adds getEventReplayStats to the ProjectionSnapshotQuery service contract and SQL implementation, returning event count and serialized payload bytes for an exclusive-lower/inclusive-upper sequence range without decoding payloads.
• Adds canReplayPersistedRange in ws.ts that rejects ranges ahead of the authoritative head, exceeding the event-gap limit, or exceeding the new 8 MiB serialized-payload budget.
• Shell and thread subscription resume paths now call this helper before reading/decoding events; rejected ranges emit a fresh snapshot followed by synchronized/live updates.
• Risk: subscriptions whose persisted ranges now exceed the 8 MiB budget or head/limit checks will silently switch from replay to snapshot delivery instead of replaying events — reviewers should check canReplayPersistedRange in ws.ts and the getEventReplayStats query in ProjectionSnapshotQuery.ts for boundary correctness.

^{Macroscope summarized adb6780.}

---

Note

Medium Risk
Changes WebSocket reconnect/catch-up behavior for shell and thread subscriptions; incorrect byte accounting could still allow heavy replay or over-snapshot clients, but the path is defensive and well-tested.

Overview
WebSocket subscribeShell and subscribeThread catch-up used to allow replay whenever the sequence gap was within the existing ~1,000-event cap, which could still decode huge tool payloads and OOM the server.

This PR adds getEventReplayStats on ProjectionSnapshotQuery, aggregating event count and serialized payload_json size in SQL via octet_length (no payload decode). canReplayPersistedRange in ws.ts requires both the gap limit and an 8 MiB payload budget (ORCHESTRATION_REPLAY_PAYLOAD_BUDGET_BYTES); otherwise the client gets snapshot + synchronized instead of replay. Test mocks are updated, plus coverage for byte measurement (including emoji) and subscription fallback when stats exceed the budget.

^{Reviewed by Cursor Bugbot for commit adb6780. Bugbot is set up for automated code reviews on this repo. Configure here.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This changes production WebSocket reconnect behavior by adding an always-on 8 MiB policy that can replace event replay with snapshot delivery and introduces a new persistence query used by both shell and thread subscriptions. The focused tests reduce risk, but the autonomous gate and its customer-visible fallback behavior warrant human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[rcawston]

What Changed

• Add a lightweight replay-range query that counts events and serialized payload bytes without decoding them.
• Fall back to a fresh snapshot when a reconnect gap exceeds the existing row limit or an 8 MiB payload budget.
• Apply the same preflight behavior to thread and shell subscriptions.
• Add focused coverage for oversized replay gaps and snapshot fallback behavior.

Why

Severity: high (regular-use blocker).

WebSocket catch-up checked only the number of missing events, then loaded and decoded the entire replay range before deciding whether it was safe to send. A small number of events can contain very large tool payloads, so reconnecting a client to a busy conversation could allocate multiple gigabytes, exhaust V8, restart the backend, and leave the client repeatedly reconnecting without a usable conversation.

Measuring the serialized range first lets the server choose the existing snapshot path before materializing unsafe payloads.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Note

Bound WebSocket orchestration replay payloads to 8 MiB and add getEventReplayStats

• Adds getEventReplayStats to the ProjectionSnapshotQuery service contract and SQL implementation, returning event count and serialized payload bytes for an exclusive-lower/inclusive-upper sequence range without decoding payloads.
• Adds canReplayPersistedRange in ws.ts that rejects ranges ahead of the authoritative head, exceeding the event-gap limit, or exceeding the new 8 MiB serialized-payload budget.
• Shell and thread subscription resume paths now call this helper before reading/decoding events; rejected ranges emit a fresh snapshot followed by synchronized/live updates.
• Risk: subscriptions whose persisted ranges now exceed the 8 MiB budget or head/limit checks will silently switch from replay to snapshot delivery instead of replaying events — reviewers should check canReplayPersistedRange in ws.ts and the getEventReplayStats query in ProjectionSnapshotQuery.ts for boundary correctness.

^{Macroscope summarized adb6780.}

---

Note

Medium Risk
Changes WebSocket reconnect/catch-up behavior for shell and thread subscriptions; incorrect byte accounting could still allow heavy replay or over-snapshot clients, but the path is defensive and well-tested.

Overview
WebSocket subscribeShell and subscribeThread catch-up used to allow replay whenever the sequence gap was within the existing ~1,000-event cap, which could still decode huge tool payloads and OOM the server.

This PR adds getEventReplayStats on ProjectionSnapshotQuery, aggregating event count and serialized payload_json size in SQL via octet_length (no payload decode). canReplayPersistedRange in ws.ts requires both the gap limit and an 8 MiB payload budget (ORCHESTRATION_REPLAY_PAYLOAD_BUDGET_BYTES); otherwise the client gets snapshot + synchronized instead of replay. Test mocks are updated, plus coverage for byte measurement (including emoji) and subscription fallback when stats exceed the budget.

^{Reviewed by Cursor Bugbot for commit adb6780. Bugbot is set up for automated code reviews on this repo. Configure here.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This changes production WebSocket reconnect behavior by adding an always-on 8 MiB policy that can replace event replay with snapshot delivery and introduces a new persistence query used by both shell and thread subscriptions. The focused tests reduce risk, but the autonomous gate and its customer-visible fallback behavior warrant human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[rcawston]

What Changed

• Add a lightweight replay-range query that counts events and serialized payload bytes without decoding them.
• Fall back to a fresh snapshot when a reconnect gap exceeds the existing row limit or an 8 MiB payload budget.
• Apply the same preflight behavior to thread and shell subscriptions.
• Add focused coverage for oversized replay gaps and snapshot fallback behavior.

Why

Severity: high (regular-use blocker).

WebSocket catch-up checked only the number of missing events, then loaded and decoded the entire replay range before deciding whether it was safe to send. A small number of events can contain very large tool payloads, so reconnecting a client to a busy conversation could allocate multiple gigabytes, exhaust V8, restart the backend, and leave the client repeatedly reconnecting without a usable conversation.

Measuring the serialized range first lets the server choose the existing snapshot path before materializing unsafe payloads.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Note

Bound WebSocket orchestration replay payloads to 8 MiB and add getEventReplayStats

• Adds getEventReplayStats to the ProjectionSnapshotQuery service contract and SQL implementation, returning event count and serialized payload bytes for an exclusive-lower/inclusive-upper sequence range without decoding payloads.
• Adds canReplayPersistedRange in ws.ts that rejects ranges ahead of the authoritative head, exceeding the event-gap limit, or exceeding the new 8 MiB serialized-payload budget.
• Shell and thread subscription resume paths now call this helper before reading/decoding events; rejected ranges emit a fresh snapshot followed by synchronized/live updates.
• Risk: subscriptions whose persisted ranges now exceed the 8 MiB budget or head/limit checks will silently switch from replay to snapshot delivery instead of replaying events — reviewers should check canReplayPersistedRange in ws.ts and the getEventReplayStats query in ProjectionSnapshotQuery.ts for boundary correctness.

^{Macroscope summarized adb6780.}

---

Note

Medium Risk
Changes WebSocket reconnect/catch-up behavior for shell and thread subscriptions; incorrect byte accounting could still allow heavy replay or over-snapshot clients, but the path is defensive and well-tested.

Overview
WebSocket subscribeShell and subscribeThread catch-up used to allow replay whenever the sequence gap was within the existing ~1,000-event cap, which could still decode huge tool payloads and OOM the server.

This PR adds getEventReplayStats on ProjectionSnapshotQuery, aggregating event count and serialized payload_json size in SQL via octet_length (no payload decode). canReplayPersistedRange in ws.ts requires both the gap limit and an 8 MiB payload budget (ORCHESTRATION_REPLAY_PAYLOAD_BUDGET_BYTES); otherwise the client gets snapshot + synchronized instead of replay. Test mocks are updated, plus coverage for byte measurement (including emoji) and subscription fallback when stats exceed the budget.

^{Reviewed by Cursor Bugbot for commit adb6780. Bugbot is set up for automated code reviews on this repo. Configure here.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This changes production WebSocket reconnect behavior by adding an always-on 8 MiB policy that can replace event replay with snapshot delivery and introduces a new persistence query used by both shell and thread subscriptions. The focused tests reduce risk, but the autonomous gate and its customer-visible fallback behavior warrant human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[rcawston]

What Changed

• Add a lightweight replay-range query that counts events and serialized payload bytes without decoding them.
• Fall back to a fresh snapshot when a reconnect gap exceeds the existing row limit or an 8 MiB payload budget.
• Apply the same preflight behavior to thread and shell subscriptions.
• Add focused coverage for oversized replay gaps and snapshot fallback behavior.

Why

Severity: high (regular-use blocker).

WebSocket catch-up checked only the number of missing events, then loaded and decoded the entire replay range before deciding whether it was safe to send. A small number of events can contain very large tool payloads, so reconnecting a client to a busy conversation could allocate multiple gigabytes, exhaust V8, restart the backend, and leave the client repeatedly reconnecting without a usable conversation.

Measuring the serialized range first lets the server choose the existing snapshot path before materializing unsafe payloads.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Note

Bound WebSocket orchestration replay payloads to 8 MiB and add getEventReplayStats

• Adds getEventReplayStats to the ProjectionSnapshotQuery service contract and SQL implementation, returning event count and serialized payload bytes for an exclusive-lower/inclusive-upper sequence range without decoding payloads.
• Adds canReplayPersistedRange in ws.ts that rejects ranges ahead of the authoritative head, exceeding the event-gap limit, or exceeding the new 8 MiB serialized-payload budget.
• Shell and thread subscription resume paths now call this helper before reading/decoding events; rejected ranges emit a fresh snapshot followed by synchronized/live updates.
• Risk: subscriptions whose persisted ranges now exceed the 8 MiB budget or head/limit checks will silently switch from replay to snapshot delivery instead of replaying events — reviewers should check canReplayPersistedRange in ws.ts and the getEventReplayStats query in ProjectionSnapshotQuery.ts for boundary correctness.

^{Macroscope summarized adb6780.}

---

Note

Medium Risk
Changes WebSocket reconnect/catch-up behavior for shell and thread subscriptions; incorrect byte accounting could still allow heavy replay or over-snapshot clients, but the path is defensive and well-tested.

Overview
WebSocket subscribeShell and subscribeThread catch-up used to allow replay whenever the sequence gap was within the existing ~1,000-event cap, which could still decode huge tool payloads and OOM the server.

This PR adds getEventReplayStats on ProjectionSnapshotQuery, aggregating event count and serialized payload_json size in SQL via octet_length (no payload decode). canReplayPersistedRange in ws.ts requires both the gap limit and an 8 MiB payload budget (ORCHESTRATION_REPLAY_PAYLOAD_BUDGET_BYTES); otherwise the client gets snapshot + synchronized instead of replay. Test mocks are updated, plus coverage for byte measurement (including emoji) and subscription fallback when stats exceed the budget.

^{Reviewed by Cursor Bugbot for commit adb6780. Bugbot is set up for automated code reviews on this repo. Configure here.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This changes production WebSocket reconnect behavior by adding an always-on 8 MiB policy that can replace event replay with snapshot delivery and introduces a new persistence query used by both shell and thread subscriptions. The focused tests reduce risk, but the autonomous gate and its customer-visible fallback behavior warrant human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[rcawston]

What Changed

• Add a lightweight replay-range query that counts events and serialized payload bytes without decoding them.
• Fall back to a fresh snapshot when a reconnect gap exceeds the existing row limit or an 8 MiB payload budget.
• Apply the same preflight behavior to thread and shell subscriptions.
• Add focused coverage for oversized replay gaps and snapshot fallback behavior.

Why

Severity: high (regular-use blocker).

WebSocket catch-up checked only the number of missing events, then loaded and decoded the entire replay range before deciding whether it was safe to send. A small number of events can contain very large tool payloads, so reconnecting a client to a busy conversation could allocate multiple gigabytes, exhaust V8, restart the backend, and leave the client repeatedly reconnecting without a usable conversation.

Measuring the serialized range first lets the server choose the existing snapshot path before materializing unsafe payloads.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Note

Bound WebSocket orchestration replay payloads to 8 MiB and add getEventReplayStats

• Adds getEventReplayStats to the ProjectionSnapshotQuery service contract and SQL implementation, returning event count and serialized payload bytes for an exclusive-lower/inclusive-upper sequence range without decoding payloads.
• Adds canReplayPersistedRange in ws.ts that rejects ranges ahead of the authoritative head, exceeding the event-gap limit, or exceeding the new 8 MiB serialized-payload budget.
• Shell and thread subscription resume paths now call this helper before reading/decoding events; rejected ranges emit a fresh snapshot followed by synchronized/live updates.
• Risk: subscriptions whose persisted ranges now exceed the 8 MiB budget or head/limit checks will silently switch from replay to snapshot delivery instead of replaying events — reviewers should check canReplayPersistedRange in ws.ts and the getEventReplayStats query in ProjectionSnapshotQuery.ts for boundary correctness.

^{Macroscope summarized adb6780.}

---

Note

Medium Risk
Changes WebSocket reconnect/catch-up behavior for shell and thread subscriptions; incorrect byte accounting could still allow heavy replay or over-snapshot clients, but the path is defensive and well-tested.

Overview
WebSocket subscribeShell and subscribeThread catch-up used to allow replay whenever the sequence gap was within the existing ~1,000-event cap, which could still decode huge tool payloads and OOM the server.

This PR adds getEventReplayStats on ProjectionSnapshotQuery, aggregating event count and serialized payload_json size in SQL via octet_length (no payload decode). canReplayPersistedRange in ws.ts requires both the gap limit and an 8 MiB payload budget (ORCHESTRATION_REPLAY_PAYLOAD_BUDGET_BYTES); otherwise the client gets snapshot + synchronized instead of replay. Test mocks are updated, plus coverage for byte measurement (including emoji) and subscription fallback when stats exceed the budget.

^{Reviewed by Cursor Bugbot for commit adb6780. Bugbot is set up for automated code reviews on this repo. Configure here.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This changes production WebSocket reconnect behavior by adding an always-on 8 MiB policy that can replace event replay with snapshot delivery and introduces a new persistence query used by both shell and thread subscriptions. The focused tests reduce risk, but the autonomous gate and its customer-visible fallback behavior warrant human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[rcawston]

What Changed

• Add a lightweight replay-range query that counts events and serialized payload bytes without decoding them.
• Fall back to a fresh snapshot when a reconnect gap exceeds the existing row limit or an 8 MiB payload budget.
• Apply the same preflight behavior to thread and shell subscriptions.
• Add focused coverage for oversized replay gaps and snapshot fallback behavior.

Why

Severity: high (regular-use blocker).

WebSocket catch-up checked only the number of missing events, then loaded and decoded the entire replay range before deciding whether it was safe to send. A small number of events can contain very large tool payloads, so reconnecting a client to a busy conversation could allocate multiple gigabytes, exhaust V8, restart the backend, and leave the client repeatedly reconnecting without a usable conversation.

Measuring the serialized range first lets the server choose the existing snapshot path before materializing unsafe payloads.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Note

Bound WebSocket orchestration replay payloads to 8 MiB and add getEventReplayStats

• Adds getEventReplayStats to the ProjectionSnapshotQuery service contract and SQL implementation, returning event count and serialized payload bytes for an exclusive-lower/inclusive-upper sequence range without decoding payloads.
• Adds canReplayPersistedRange in ws.ts that rejects ranges ahead of the authoritative head, exceeding the event-gap limit, or exceeding the new 8 MiB serialized-payload budget.
• Shell and thread subscription resume paths now call this helper before reading/decoding events; rejected ranges emit a fresh snapshot followed by synchronized/live updates.
• Risk: subscriptions whose persisted ranges now exceed the 8 MiB budget or head/limit checks will silently switch from replay to snapshot delivery instead of replaying events — reviewers should check canReplayPersistedRange in ws.ts and the getEventReplayStats query in ProjectionSnapshotQuery.ts for boundary correctness.

^{Macroscope summarized adb6780.}

---

Note

Medium Risk
Changes WebSocket reconnect/catch-up behavior for shell and thread subscriptions; incorrect byte accounting could still allow heavy replay or over-snapshot clients, but the path is defensive and well-tested.

Overview
WebSocket subscribeShell and subscribeThread catch-up used to allow replay whenever the sequence gap was within the existing ~1,000-event cap, which could still decode huge tool payloads and OOM the server.

This PR adds getEventReplayStats on ProjectionSnapshotQuery, aggregating event count and serialized payload_json size in SQL via octet_length (no payload decode). canReplayPersistedRange in ws.ts requires both the gap limit and an 8 MiB payload budget (ORCHESTRATION_REPLAY_PAYLOAD_BUDGET_BYTES); otherwise the client gets snapshot + synchronized instead of replay. Test mocks are updated, plus coverage for byte measurement (including emoji) and subscription fallback when stats exceed the budget.

^{Reviewed by Cursor Bugbot for commit adb6780. Bugbot is set up for automated code reviews on this repo. Configure here.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This changes production WebSocket reconnect behavior by adding an always-on 8 MiB policy that can replace event replay with snapshot delivery and introduces a new persistence query used by both shell and thread subscriptions. The focused tests reduce risk, but the autonomous gate and its customer-visible fallback behavior warrant human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[rcawston]

What Changed

• Add a lightweight replay-range query that counts events and serialized payload bytes without decoding them.
• Fall back to a fresh snapshot when a reconnect gap exceeds the existing row limit or an 8 MiB payload budget.
• Apply the same preflight behavior to thread and shell subscriptions.
• Add focused coverage for oversized replay gaps and snapshot fallback behavior.

Why

Severity: high (regular-use blocker).

WebSocket catch-up checked only the number of missing events, then loaded and decoded the entire replay range before deciding whether it was safe to send. A small number of events can contain very large tool payloads, so reconnecting a client to a busy conversation could allocate multiple gigabytes, exhaust V8, restart the backend, and leave the client repeatedly reconnecting without a usable conversation.

Measuring the serialized range first lets the server choose the existing snapshot path before materializing unsafe payloads.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Note

Bound WebSocket orchestration replay payloads to 8 MiB and add getEventReplayStats

• Adds getEventReplayStats to the ProjectionSnapshotQuery service contract and SQL implementation, returning event count and serialized payload bytes for an exclusive-lower/inclusive-upper sequence range without decoding payloads.
• Adds canReplayPersistedRange in ws.ts that rejects ranges ahead of the authoritative head, exceeding the event-gap limit, or exceeding the new 8 MiB serialized-payload budget.
• Shell and thread subscription resume paths now call this helper before reading/decoding events; rejected ranges emit a fresh snapshot followed by synchronized/live updates.
• Risk: subscriptions whose persisted ranges now exceed the 8 MiB budget or head/limit checks will silently switch from replay to snapshot delivery instead of replaying events — reviewers should check canReplayPersistedRange in ws.ts and the getEventReplayStats query in ProjectionSnapshotQuery.ts for boundary correctness.

^{Macroscope summarized adb6780.}

---

Note

Medium Risk
Changes WebSocket reconnect/catch-up behavior for shell and thread subscriptions; incorrect byte accounting could still allow heavy replay or over-snapshot clients, but the path is defensive and well-tested.

Overview
WebSocket subscribeShell and subscribeThread catch-up used to allow replay whenever the sequence gap was within the existing ~1,000-event cap, which could still decode huge tool payloads and OOM the server.

This PR adds getEventReplayStats on ProjectionSnapshotQuery, aggregating event count and serialized payload_json size in SQL via octet_length (no payload decode). canReplayPersistedRange in ws.ts requires both the gap limit and an 8 MiB payload budget (ORCHESTRATION_REPLAY_PAYLOAD_BUDGET_BYTES); otherwise the client gets snapshot + synchronized instead of replay. Test mocks are updated, plus coverage for byte measurement (including emoji) and subscription fallback when stats exceed the budget.

^{Reviewed by Cursor Bugbot for commit adb6780. Bugbot is set up for automated code reviews on this repo. Configure here.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This changes production WebSocket reconnect behavior by adding an always-on 8 MiB policy that can replace event replay with snapshot delivery and introduces a new persistence query used by both shell and thread subscriptions. The focused tests reduce risk, but the autonomous gate and its customer-visible fallback behavior warrant human review.

^{You can add or adjust custom eligibility rules. Learn more.}