feat(playback): buffer the next track early, look further ahead less

The served Vibe preview was eight items deep, and every one of them cost
a track fetch on each advance while buying nothing but a longer Up next
list. Three is enough to show where the stream is going.

The audio prefetch was the opposite problem: it only began twenty
seconds before the end, so a phone that lost signal in that window
arrived at the handover with nothing buffered. It now starts fifteen
seconds into the current track, which gives the rest of the song to pull
the next one down. Buffering that early means a replan can change the
answer, so the idle element is re-pointed when it does.

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

backend/src/services/vibe-session-coordinator.service.ts

@@ -48,6 +48,15 @@ export interface AdvanceUnplayableVibeItemInput {
   eventId: string;
 }
 
+/**
+ * How much of the plan a client is shown and holds ready. The plan itself is
+ * PLAN_SIZE long and stays that way; this is only the served window. Every
+ * preview item costs the client one track fetch on every advance, and a replan
+ * discards whatever is still unplayed, so a long window buys little beyond a
+ * longer Up next list.
+ */
+const PREVIEW_SIZE = 3;
+
 export class VibeSessionNotFoundError extends Error {}
 export class VibeSessionLifecycleError extends Error {}
 export class VibePlanNotFoundError extends Error {}
@@ -339,7 +348,7 @@ export class VibeSessionCoordinator {
   ): VibeSessionResponse {
     // A revision is immutable, but clients need a live future: already served
     // rows stay in the ledger and are excluded from the replacement preview.
-    const preview = plan?.items.filter((item) => !item.committed).slice(0, 8) ?? [];
+    const preview = plan?.items.filter((item) => !item.committed).slice(0, PREVIEW_SIZE) ?? [];
     return {
       session,
       sessionId: session.id,