fix(ws): take a preview PiP to program from a macro

[wagenet]

Top of a three-PR stack: #182 (harness) → #179 (displace a PGM PiP) → this. The diff contains all three commits until those merge — only the third, fix(ws): take a preview PiP to program from a macro, belongs to this PR.

Problem

A macro TAKE never promotes a PiP sitting in preview, and the failure is silent rather than merely stale.

SELECT_PVW_PIP sets newTally = { pgm: tally.pgm, pvw: null }, so tally.pvw is null whenever a PiP is in preview. The macro TAKE then does:

const newTally = { pgm: tally.pvw, pvw: tally.pgm };   // → { pgm: null, pvw: <old pgm> }
broadcast(productionId, { type: 'TALLY', ...newTally });
await stromTransition(currentDoc, fromPad, tally.pvw, 'cut');
//                                         ^^^^^^^^^ null → early return on !toMixerInput

So every subscriber is told the program bus went empty, Strom is never called and keeps airing the previous source, and pgmPipByProduction is never set — the server does not know the PiP took either. The operator sees a macro that appears to do nothing while the tally says the show went black.

Fix

Restructures the macro TAKE to mirror the interactive handler's three branches — PiP moving PVW→PGM, PiP moving PGM→PVW, and no PiP — instead of the single displacement path that only covered the second.

The pip maps are now swapped as a pair (newPgmPip = curPvwPip, newPvwPip = curPgmPip) rather than cleared, and PIP_STATE is emitted unconditionally, both matching the interactive TAKE.

The forward branch reuses pvwBeforePipByProduction as to_input and records it as the new pgmBg, so a later CUT or TRANSITION while the PiP is on program has a background to report and Strom keeps pgm_input ≠ pvw_input.

Impact

The selectPreview({ source: { pip: N } }) and transition pair in the forward branch is what reaches the mixer — previously no Strom call was made at all on this path. trigger_transition reads the authoritative PGM/PVW source from overlay state (gst/pipeline/effects/take.rs), which selectPreview is what sets.

As in #179, the from_input/to_input values are carried for consistency with the interactive handler rather than as a fix; Strom reads them only when overlay state is missing.

With no PiP on either bus, the new else branch is the previous behaviour unchanged.

Conflicts with #156

Same five hunks as #179 — three in src/ws/controller.ts, two in src/__tests__/ws-macro-pip.test.ts — since this PR carries #179's commit until that merges. Mechanical, and I will rebase whichever lands second.

Testing

Ships with the harness case it makes pass. That case asserts Strom is called at all on this path, which is precisely what the previous behaviour got wrong — it fails against #179 and passes here.

• npx vitest run src/__tests__/ws-macro-pip.test.ts — 4 passed.
• npx tsc --noEmit clean.
• npx vitest run — the suite's 27 pre-existing failures in activation.test.ts and macros.test.ts are unchanged and present on main too.
• Not exercised against a live mixer. Strom builds and runs locally, but neither of its sample flows carries a vision mixer block and its own suite has no PiP coverage, so Strom's response to selectPreview({pip:N}) rests on reading flows.rs and mixer_ops.rs rather than on execution.

[birme]

This PR is part of a multi-PR dependency stack (the WS macro / PiP fixes), in dependency order:

• test(ws): add a harness for the WS controller macro paths #182 — WS-controller macro test harness (already MERGED)
• fix(ws): displace a PGM PiP when a macro cuts, transitions, or takes #179 — displace a PGM PiP when a macro cuts/transitions/takes
• fix(ws): take a preview PiP to program from a macro #180 — take a preview PiP to program from a macro

Holding off on automated review/merge here — both open PRs are drafts and each still carries the other's commits until the one below it merges, so they need a human (or the relevant dev agent) to assess the stack as a whole, not a per-PR pass. Nothing further is needed from the author; this comment records the dependency on the PR itself rather than only in a run log.