feat: picture-in-picture — a small input preview inset in a corner

[BernardJen]

Split out of #239, preserved from TODO.md before its deletion (#208).

What

One input filling the wall with a second shown small in a corner.

Current state

Not implemented — no pictureInPicture or picture-in-picture anywhere in src/.

Notes

Lower value than #244 (multi-view) and overlaps it: on a 5:1 wall a corner inset is a small
rectangle in a very wide frame, where multi-view gives every input a whole panel. Worth doing
only if the case is specifically "one main feed plus a glance at another" rather than
"several feeds at once".

Placement is not obvious either. On 16:9 a corner is conventional; on 6000×1200 the corners are
nearly 3m apart, so which corner is a real decision rather than a default.

Acceptance criteria

• A layout with one main input and one inset
• Inset corner and size configurable
• Defined behaviour when the inset's input loses signal
• Documented in the user guide

[BernardJen]

Depends on #261.

This issue needs more than two simultaneous capture feeds, and the app currently supports exactly
two — not as a parameter but as its shape: 10 state fields keyed by side, 10 elements entries,
9 functions taking a side argument, 15 side === 'left' ? a : b ternaries, and three objects
literally shaped { left, right }.

Filed as #261 rather than repeated here, because #242, #244 and #245 all need the same thing and
solving it three times would produce three incompatible ways to hold N feeds.

Two things from #261 worth knowing before this is designed:

It is not established that the hardware can do it. Four simultaneous getUserMedia streams
from four capture cards has never been tried on the wall's host. Cards sharing a USB controller
contend for bandwidth and tend to renegotiate down or drop frames rather than fail loudly. The
answer could change what this feature looks like.

The WebGPU compositor silently drops the third feed. Its draw(feeds) API takes an array, but
it allocates two uniform buffers and skips anything past index 1 with no warning. Anyone building
against it would see two panels work and a third go black for no stated reason.

[BernardJen]

Closing as not planned — the wall is not going to be used this way.

One correction for the record, since the note above is wrong: this never depended on
#261. Picture-in-picture is one input filling the wall plus a second shown small, which
is two simultaneous streams — exactly what dual view already runs today. It needed layout
work, not capture-stream work.

I posted that dependency on #242, #244 and #245 together without checking each against its
own stream count. #242 genuinely needs four; this needed two and already had them.