Context

The call bar sat at the top center of the screen. Testers wanted to move it to a side or a corner, and to stand it up beside the screen. It's a window of its own, above everything, kept out of the shared screen. Moving it should snap to sensible places, work the same on macOS and Windows, work without a mouse, and open where it was left in the next call.

Decision

Eight places, two layouts. The bar sits at the top, the bottom, the left, the right or a corner of the screen's usable area. Left and right stand it up (vertical); top and bottom lay it flat; a corner keeps the layout it had. The window grows toward the middle of the screen when a menu opens.
Short Leash moves the window, not the system. Once a press on the handle moves 4 px, the page tells the app shell, which moves the window with the pointer and shows the eight targets in a click-through, content-protected window (pair-snap) in the panels' snap-target look (0031). On release the shell picks the nearest place and glides there, or moves at once with reduced motion. The system's own window drag would hide when it ends on Windows.
Keyboard and menu too. Clicking the handle opens Layout and Move to; the arrow keys on the handle step to the next place.
Kept by the app, not leashd. The place and layout are window placement, so they live in pair-bar.json in the app's config folder next to the panels' layout, written as a private file, and are read each time the bar opens.

Consequences

One more window during a drag, closed on release. A drag whose release is never reported ends itself after two minutes.
The place follows the person, per computer, and isn't part of config.toml or the API state.
Dragging and the glide can only be checked in the app (just dev), not in the browser review of the UI.