fix(node): a seek left the audio a GOP behind the picture

-ss before -i cannot trim copied video, which must begin on a keyframe, but
accurate_seek did trim the re-encoded audio to the exact request. Every seek
on a copied stream therefore opened with a GOP-wide hole in the audio and ran
a GOP out of sync afterwards — 9.979s on a real film with a 10s keyframe
interval. Accurate seeking is now off wherever video is copied, and stays on
where it is re-encoded, which is the only path that could already begin where
it was asked to.

Every timestamp was correct throughout, which is why nothing caught it; the
tests assert on decoded audio and on frames compared against the source.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1 files changed, 15 insertions, 0 deletions

diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index e7d4a76..ef65995 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -2031,6 +2031,21 @@ MSE string) fed to a source buffer, with the node holding one slot per viewer.
 - **Seeking restarts the source with an index seek before the input**, clamped away
   from the end and echoed back; the client supplies the timestamp offset, because
   copying timestamps does not preserve position.
+- **A seek trims what it can, and what it can differs per stream — which is a
+  desync, not an inconvenience.** Accurate seeking cannot trim copied video, which
+  must begin on a keyframe, but it does trim re-encoded audio to the exact request.
+  The output then carries video from the keyframe and audio from the request, a
+  whole GOP apart, with a hole between them. So **accurate seeking is off wherever
+  video is copied and on wherever it is re-encoded**, which is the only place the
+  two can agree on where to begin.
+
+  > **Every timestamp was correct while this was happening.** First PTS per stream,
+  > durations, spans, and the browser's own audio/video delta through MediaSource
+  > all agreed, because both streams genuinely sat where the container said. Only
+  > the *content* at a given instant was displaced. A property that every
+  > timestamp-shaped check confirms is not thereby true: this one needed the output
+  > decoded and compared against the source, frame against frame and envelope
+  > against envelope.
 - **The viewer picks the audio track, and picking one is a seek.** One ffmpeg
   carries one audio track, so there is nothing to switch inside a running stream:
   the node is asked again at the current position and the source buffer is reset