fix(tiles): pin the Tiles wall at 1080p so preview no longer drops on-air members

[iamfatness]

The report

"CoreVideo tiles participants are dropping as I go through different people in preview" — a few hundred ms, then their color changes.

Root cause (confirmed live)

A wall member sits at program-tiles = 720p. Soloing them in Preview makes them a preview route = 1080p. Resolution is part of the Zoom engine's subscription key, so 720p→1080p is a genuine renderer destroy/create on a source that is live on the Program wall — that teardown is the drop, and the "color change" is the colorFromParticipantId placeholder slab painted until the rebuilt feed lands. Moving to the next person flips the previous one 1080p→720p — a second teardown.

It is one feed flipping, not two grabs: m_subs is keyed by participant_id, and every surface (wall tile, preview, program) renders that single decoded frame. So the wall tile and the preview are already the same feed at two sizes — the bug is purely the resolution key changing.

Fix

Tiles (program-tiles / preview-tiles) now request 1080p, the highest tier — so a soloed wall member has no lower tier to fall back to. Same feed, no re-subscribe, no drop.

That required raising the concurrent-1080p cap, which is the historically dangerous part: the cap of 4 exists because 6 concurrent 1080p crashed the SDK subprocess (0xc000000d) — but that was measured on the 2026-06 CPU-I420 path.

Soak-proven before shipping

Live, real 8-person meeting, all 8 wall members at 1080p on Program for 30+ minutes:

render / delivered	60.0/s / 60.0/s
underruns / skipped / gpuNotReady	0 / 0 / 0
monitor shedding	none
engine subprocess	never crashed or respawned
totalChurn across a full operator preview run	flat (per-source churn = 1, the one-time take)

The old build climbed ~30 churn events per minute of previewing; this one held flat, owner-confirmed ("looks good to me").

Cap = 8, deliberately

8 is the number the soak proved and the meeting's camera count. Not raised higher on extrapolation — the constant's standing rule. Graceful past 8: wall members are granted before the wall background in payload order, so a 9th 1080p source (a live wall background, a >8 wall, a non-wall bus route) is demoted to 720p stably rather than flipping a member. Screen share is 1080p and bypasses the camera counter, so 8 wall + a share = 9 concurrent 1080p — one step past what was soaked, flagged in the code and docs to watch.

Follow-ups (not in this PR)

• A wall larger than 8, or a full wall + screen share, needs a bigger-meeting soak before the cap goes above 8.
• ZoomSourceSetPolicy's purpose-override still stamps an on-air wall member preview when soloed; harmless for resolution now (both 1080p) but semantically off — cleanup, not a fix.

Tests

The old ACueRaisesOnceTheTakeSendsNothingAndLeavingTheBusDropsBack asserted the exact behavior this removes; rewritten as AWallMemberCuedToPreviewDoesNotReSubscribe (a wall member cued to preview sends nothing). Tier + cap assertions updated. 931 native tests pass.

🤖 Generated with Claude Code

https://claude.ai/code/session_014yuH7EMvWCWdkhvevrtMyJ