refactor: the two-feed limit, the compositor's silent third-feed drop, and how many streams the wall sustains

[BernardJen]

Split out of #242, #244 and #245, none of which mentions it.

What

The app can show exactly two capture feeds. Three open features each need more than two, and
each is written as though the feeds were the easy part. This is the work underneath all three, and
it is almost certainly larger than any of them.

Current state

Two <video> elements, #left-video and #right-video
(index.html:17 and
:41), and "left or right" is not a parameter —
it is the shape of the renderer:

	Count
state fields keyed by side	10 (leftDeviceId/rightDeviceId, leftStream, leftAudioGain, leftAudioSource, leftVolume, and their right-hand twins)
elements entries keyed by side	10 (leftFeed, leftVideo, leftBorder, leftInputList, leftLabel, ×2)
functions taking a side argument	9
side === 'left' ? a : b ternaries	15
objects literally shaped { left, right }	3 (mockStreams, noSignalBoards, swapToken)

getUniqueActiveDevices() hand-enumerates left then right rather than iterating feeds, so
detection, the no-signal overlays, the split-flap boards and the swap-fade tokens all inherit the
same two-slot shape.

The GPU compositor is a partial head start, with a trap in it

gpu-compositor.js already takes an array — draw(feeds), each with its own offset and scale
in normalised target space (gpu-compositor.js:139).
That is the right shape and it did not have to be.

But it allocates exactly two uniform buffers:

const uniforms = [0, 1].map(() => device.createBuffer({ size: 32, ... }))

and then, per feed:

if (i >= uniforms.length) return

A third feed is silently dropped. No error, no warning — it just does not draw. Anyone wiring
up multi-view against this compositor would get two panels working and a third that is black for no
stated reason. Worth fixing on its own merits even if none of the three features are built:
either allocate from feeds.length or log what was discarded.

Note this is behind gpuCompositing in settings and off by default, so the CSS path is the one
that actually runs on the wall today.

What is genuinely unknown

Whether the hardware can do it at all. Four simultaneous getUserMedia streams from four
capture devices is not obviously fine: capture cards sharing a USB controller contend for
bandwidth, and several will renegotiate to a lower resolution or drop frames rather than fail
loudly. Nobody has tried it here. This should be measured before any of #242/#244/#245 is designed
around it, because the answer could change what they look like — a thumbnails panel that has to
poll inputs one at a time is a different feature from one showing four live streams.

#248 makes that measurement cheap on the software side. --mock=8 synthesises eight inputs as
real MediaStreams from canvas.captureStream(), so the renderer work can be built and driven
with no capture hardware present. It cannot answer the USB-bandwidth question, which needs real
cards, but it separates "does our code handle N feeds" from "does the hardware".

Why this is one issue rather than three

#242 (thumbnails panel), #244 (multi-view) and #245 (picture-in-picture) are genuinely different
features — a transient picker, a per-panel layout, and a persistent inset. They are not duplicates
and this is not a proposal to merge them.

They just share one dependency, and doing it three times would produce three incompatible ways to
hold more than two feeds. #243 (auto-switch) is orthogonal and does not need this.

Acceptance criteria

• Feeds held in a collection rather than as left/right fields, with the count not fixed in
  the markup
• Detection, no-signal overlays, split-flap boards and the swap-fade tokens all derive from that
  collection instead of enumerating two sides
• D/S and the existing dual/single behaviour unchanged — this is a refactor with no
  user-visible change on its own
• The WebGPU compositor allocates uniforms from the feed count, or logs what it drops
• Measured: how many simultaneous real capture streams the wall's host actually sustains, and
  what happens at the limit — recorded here
• Verified with --mock=8 that the renderer handles more feeds than there are number keys
• Audio mixing decided for more than two feeds, or explicitly deferred with the reason

[BernardJen]

Two of the three issues this was filed for are closed as not planned (#244, #245), and the
third never needed all of it. Retitling and narrowing.

The case for this issue was that #242, #244 and #245 shared a dependency and solving it three
times would produce three incompatible ways to hold N feeds. That case is gone:

• feat: picture-in-picture — a small input preview inset in a corner #245 never depended on this at all. Picture-in-picture is one input filling the wall plus
  a second shown small — two simultaneous streams, which dual view already runs. I posted the
  dependency on all three without checking each against its own stream count.
• feat: multi-view — a different input on each panel of the videowall #244 depended on it only under its strictest reading. If panels were allowed to repeat an
  input, it needed no stream work either. Closed as not planned regardless.
• feat: thumbnails on the dropdown input rows, snapshotted when it opens #242 is the only remaining consumer, and it does genuinely need four: a panel showing a
  live preview of all four inputs at once.

What is still worth doing, and what is not

The left/right refactor was justified by three features needing it. With one consumer, the
10 state fields, 10 element entries, 9 side functions and 15 ternaries are no longer obviously
worth rewriting — #242 could plausibly be built by previewing inputs one at a time instead, which
the open question below was always the deciding factor for.

One piece stands on its own merits and should be done whether or not the rest is:

• The WebGPU compositor silently drops any feed past the second. draw(feeds) takes an
  array, but it allocates two uniform buffers and skips the rest with if (i >= uniforms.length) return — no error, no warning. Anyone wiring up a third feed gets a black panel and no
  explanation. Allocate from feeds.length, or log what was discarded.

And one measurement is still the thing that decides #242's shape:

• How many simultaneous real capture streams the wall's host sustains, and what happens at the
  limit. Cards sharing a USB controller contend for bandwidth and tend to renegotiate down or
  drop frames rather than fail loudly. A thumbnails panel that has to poll inputs one at a time
  is a different feature from one showing four live streams. --mock=8 (feat: --mock and --no-signal test flags, to exercise the no-signal and screensaver paths #248) separates "does
  our code handle N feeds" from "does the hardware", but only real cards answer the second half.

The N-feed refactor itself is left here as context rather than as agreed work. It should not be
started before that measurement, and possibly not at all.

[BernardJen]

Closing — the last consumer has gone away.

This was filed as the shared dependency under #242, #244 and #245. All three are now resolved
without it:

• feat: picture-in-picture — a small input preview inset in a corner #245 never needed it. Two streams; dual view already runs two.
• feat: multi-view — a different input on each panel of the videowall #244 closed as not planned.
• feat: thumbnails on the dropdown input rows, snapshotted when it opens #242 has settled on snapshots taken when the dropdown opens, iterating the inputs one at a
  time rather than four live previews. At most one extra stream is open at any moment, which the
  app can already do.

So the left/right refactor — 10 state fields, 10 element entries, 9 side functions, 15
ternaries — has no feature asking for it. Rewriting it speculatively is exactly the kind of work
that ages badly, and the two-feed shape is a perfectly good fit for a wall that shows one or two
feeds.

The measurement is also moot. How many simultaneous capture streams the host sustains only
mattered because #242 might have needed four. Iterating never needs more than one at a time, so
the USB-bandwidth question does not arise.

One thing recorded rather than fixed

The WebGPU compositor drops any feed past the second silently: draw(feeds) takes an array, but
allocates two uniform buffers and skips the rest with if (i >= uniforms.length) return — no
error, no warning.

Not filed separately, because it is unreachable today. gpuFeedLayout() returns at most two
entries, and the GPU path is off by default (gpuCompositing ?? false). It is a trap for whoever
next passes a third feed, not a live defect, and it is written down here so that person finds it
rather than debugging a black panel.