vv webcam Unit 1: the vertical (9:16) tier keeps its OWN camera placement per scene

The vertical tier is a centred band crop of the SAME 1920x1080 master (band x
656.25, w 607.5, h 1080), so the 16:9 camera placement (x~1408) falls outside the
cropped window and the creator is simply not in the vertical stream. Each scene
now keeps its own vertical position, size and shape; switching back to 16:9
restores the desktop layout exactly (the creator's locked table, 2026-10-17).

Geometry only - NO render-path change. The preview and the compositor both read
the element's own X/Y/W/H + ClipShape, so the tier switch swaps the LIVE geometry:
- Models/VerticalCameraLayout.cs (new): the pure math - the band, its two 607x540
  areas, the six spots (top/bottom x left/centre/right), the 32px inset and the
  270x152 default tile (480x270 in the 1080x1920 output) in the bottom-right spot,
  the corner the 16:9 default webcam uses.
- Models/WebcamSceneConfig.cs: the vertical placement lives in seven additive
  columns (VerticalX/Y/Width/Height/ClipShape/RectWidth/RectHeight; NULL = "this
  scene has no vertical placement yet"). The 16:9 layout stays in the old columns
  and is parked in the transient Landscape* fields while the vertical tier is
  live; Begin/EndVerticalLayout + CommitLiveLayoutToVertical do the swap. The
  X/Y/W/H overrides clamp every write into the band - outside it the camera is
  invisible in the vertical output.
- Models/SceneElement.cs: X/Y/Width/Height became virtual so the derived element
  constrains every writer (drag, resize handle, typed fields) in ONE choke point
  instead of three writers each re-implementing the rule.
- ViewModels/MainViewModel.Webcam.cs + .Streaming.cs: IsVerticalTier/VerticalBand,
  ResolveVerticalCameraLayout(s) (the tier swap), MoveWebcamInVerticalTier /
  SnapWebcamInVerticalTier (the six-spot snap, by the tile's centre),
  EnsureVerticalCameraLayout; ApplyStreamQuality is the tier-change hook. The
  Live scene gets its small tile automatically on the first vertical switch (the
  vertical stream would otherwise have no camera at all); the other scenes keep
  their 16:9 placement until the creator drags them into the band.
- Controls/PreviewPane.xaml.cs: the drag/resize route through the VM snap under
  the vertical tier instead of free-floating over the master.
  Controls/LeftPanel.xaml: the webcam properties gained a Geometry section
  (X/Y/W/H) for the manual entry the creator asked for, bound to the LIVE
  placement, gated on the VM's IsWebcamSelected (NOT SelectedElement.IsWebcam -
  the TASK 51 test finds that panel by binding text and would match twice).
- The store: seven guarded ADD COLUMNs, the INSERT/SELECT extended, and the
  X/Y/W/H/ClipShape columns stay the 16:9 layout - while the vertical tier is
  live the save writes the parked values there and the live ones into Vertical*.

Test: ytLive.Tests/VerticalWebcamLayoutTests.cs - the ONE Good Dog test. The
vertical tier brings the Live camera INTO the band as a small tile; dragging it to
the top-right lands it top-right inside the band; back to 16:9 the desktop layout
is restored exactly (1408/778/480x270); both placements survive a save + reload.
Full suite 429/429, 0 warnings. LayerReorderPersistenceTests.RealMouseDrag fails
ALONE on a clean tree in this environment - pre-existing flake, proven by stashing
this work, not a regression.

Derivative work: OBS has no built-in per-aspect-ratio layout storage - the
maintainers' answer is "create a second scene and add the scene you want to send
as source" (obsproject.com/forum/threads/161307) - and Streamyard's dual-aspect
guide says the same ("no built-in way to store separate layouts per aspect ratio",
so you rely on manual workarounds and plugins):
https://streamyard.com/blog/dual-aspect-ratio-streaming-tool
Our per-scene, per-tier stored placement, resolved on the tier change, is the
step past both.

Memory in the same commit: ai.md (new section), TASKS.md + TASKS/task-57-*.md
(Unit 1 shipped, Unit 2 = the Chat scene still open), HANDOFF.md, MyMistakes.md
(the per-tier geometry-swap recipe, the binding-text panel trap, the store's
webcam-identity rule) and the Models/Services/ViewModels/Controls index rows.

ai.md

@@ -703,6 +703,72 @@ which also `ScheduleSave`s). Per raw frame a background worker (latest-frame-dro
   (`BlurRadius(0.5)` = 2, `BlurRadius(1)` = 6) and the behaviour at a step edge: default smears
   light ~9px into the dark half vs ~26px at full strength.
 
+### Vertical (9:16) tier camera placement (TASK 57 — "vv" Unit 1, built 2026-10-21)
+
+**The problem.** The vertical tier (1080×1920) is a centred **band crop** of the SAME 1920×1080
+master: `OutputRect*` = x 656.25, y 0, w 607.5, h 1080. A camera placed for 16:9 (the default
+webcam sits at x≈1408) lands **outside the cropped window entirely** — in the vertical stream the
+creator is simply not in the picture.
+
+**The rule (creator's locked table, 2026-10-17).** Each scene keeps its **own** vertical
+placement — position, size and shape — and switching back to 16:9 restores the desktop layout
+exactly:
+
+| mode | shape | size | position |
+|---|---|---|---|
+| 16:9 | as today | as today | as today |
+| **vv · Live** | circle **or** rect (the creator's choice, per scene) | small tile | one of **six** spots: top/bottom × left/centre/right |
+| vv · Chat | *Unit 2* (rect only; normal, or enlarged to one 607×540 area) | — | — |
+| Starting / BRB / Ending | unchanged | unchanged | unchanged |
+
+**Design — geometry only, no render-path change.** The preview and the compositor both read the
+element's OWN `X`/`Y`/`Width`/`Height` + `ClipShape`, so the tier switch **swaps the live
+geometry** instead of teaching the render path about tiers:
+
+- `WebcamSceneConfig` carries the vertical placement (`VerticalX/Y/Width/Height/VerticalClipShape`
+  + `VerticalRectWidth/Height` — seven additive DB columns, NULL = "this scene has no vertical
+  placement yet") and the **parked** 16:9 layout (`LandscapeX/…/LandscapeRectHeight`, transient).
+- `BeginVerticalLayout(...)` parks the live 16:9 layout and brings the vertical one in;
+  `EndVerticalLayout()` commits the vertical placement back into the stored slot and restores the
+  parked 16:9 layout. The live geometry IS the render input → **the compositor and
+  `PreviewPane.xaml` are untouched**.
+- The save keeps the X/Y/W/H/ClipShape columns as the **16:9** layout (while the vertical tier is
+  live, the parked values are written there and the live ones into the `Vertical*` columns).
+- `SceneElement.X/Y/Width/Height` became **virtual** so the webcam can CONSTRAIN every write
+  (drag, resize handle, properties fields) into the band — one choke point instead of three
+  writers re-implementing the rule. Outside the band = invisible in the vertical stream.
+
+**The band and the six spots** (`Models/VerticalCameraLayout.cs`, pure math): the band is
+656.25…1263.75 × 0…1080; it splits into two 607×540 areas (top/bottom), each with three columns
+(left/centre/right) → six spots. A tile snaps to the spot its **centre** falls in, inset 32 master
+px from the band's outer edge (the app's own placement margin) and never outside the band. The
+default tile is **270×152 master px** (480×270 in the 1080×1920 output) in the **bottom-right**
+spot — the corner the 16:9 default webcam uses. The Live scene gets that tile automatically the
+first time the vertical tier is picked (otherwise the vertical stream has no camera at all); the
+other scenes keep their 16:9 placement until the creator drags them into the band.
+
+**Manual entry** (creator rule): the webcam's Layers properties gained a **Geometry** section
+(X/Y/W/H) — it edits the LIVE placement, i.e. the one the current tier shows. The webcam's
+geometry setters clamp it into the band, so a typed value can never push the camera out of the
+cropped window.
+
+**Derivative work.** OBS has no built-in way to store a scene's layout per aspect ratio — the
+maintainers' answer is "create a new empty scene and add the scene you want to send as source"
+(obsproject.com/forum/threads/…161307), and Streamyard's dual-aspect guide says the same ("no
+built-in way to store separate layouts per aspect ratio, so you rely on manual workarounds and
+plugins" — streamyard.com/blog/dual-aspect-ratio-streaming-tool). Our per-scene, per-tier stored
+placement, resolved on the tier change, is the step past that.
+
+**Tests.** `VerticalWebcamLayoutTests` — the ONE integration test for the unit: the vertical tier
+is picked → the Live camera comes INTO the band as a small tile → dragged to the top-right it
+lands top-right inside the band → back to 16:9 the desktop layout is restored exactly → and both
+placements survive a save + reload. (The store writes the webcam rows only when the app has a
+webcam identity — the config rows hang off it — so the test supplies one.)
+
+**Known trap (see `MyMistakes.md`):** a second properties panel bound to `SelectedElement.IsWebcam`
+broke `WebcamBackgroundPillTests` — that test finds the webcam's panel by **binding text**, so a
+new panel must use a different binding (`IsWebcamSelected`) or the selector matches twice.
+
 ### Frame cadence — how a dropped frame became measurable (UNIT 0, 2026-10-05)
 
 **The problem this exists to solve.** The recorded file cannot distinguish a dropped camera frame