fix(web): repair response stream sequence gaps

[sam-saffron-jarvis]

What

Add a hard sequence-continuity guard to the web response stream resume path.

If the browser believes it has applied sequence 4 and the replay stream starts at 7, the client now treats that as corruption, stops applying the tail, fetches the authoritative response snapshot, and resumes from the snapshot cursor instead of displaying 1,2,3,4,[missing],7,8,9.

Also fixes the server-side source of real holes: if a response event payload fails JSON encoding after reserving the next sequence number, the run now rolls the sequence counter back instead of burning a permanent gap.

Why

The UI was using lastSequenceNumber as both:

1. a transport cursor for /v1/responses/:id/events?after=N, and
2. an implied proof that the local DOM/session projection contains every event through N.

That second invariant was not enforced. If replay/repair returned a non-contiguous event tail, or the local projection had already drifted, the browser could accept later events and permanently skip the missing middle.

The fix makes the invariant explicit: lastSequenceNumber + 1 must be the next event. If not, snapshot repair is mandatory.

Tests

• Added JS harness coverage for replay gap repair via snapshot.
• Added Go coverage that event marshal failures do not burn response sequence numbers.
• Ran mise exec -- node internal/serveui/static/app_stream_test.js successfully.
• Ran go test ./... successfully.