refactor(studio): place the selection chrome from rect variables on one wrapper

[miguel-heygen]

What

The selection chrome now takes its position from four CSS variables on one wrapper. The resize dots, the rotate handle, the rotation plane's transform-origin and the crop frame are each placed with calc() over --hf-chrome-left/top/width/height, and React writes those four variables from overlayRect at render. Every on-screen position is the same as before.

This is the first half of taking the chrome's React work off pointermove. Today every move or resize pointermove sets the overlay rect state, and about ten chrome components re-render on every step. The follow-up change in the gesture handler will write these four variables on the wrapper per pointermove, so the whole chrome follows with one style write and the rect state is set once on release. On its own this PR changes no per-frame cost, and the selection box itself keeps its numeric position until the gesture-side change, because the gesture handler still writes box.style directly.

The variable names have one owner, domEditChromeRect.ts.

Test

DomEditSelectionChrome.test.tsx, "moves every handle with the rect while their own styles stay the same":

• it renders the chrome at two different rects;
• it checks that the six handles' own left/top styles are identical between the two renders, so only the wrapper changes;
• it resolves each handle's calc() against the wrapper's variables and checks it lands where the numeric formula used to put it (dots, rotate handle, crop frame).

On main's source it fails: the handle styles differ between the rects.

[github-actions]

Edit accuracy: 434 passing here, 434 on the base branch

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

[miguel-heygen]

Closing on measurement. On the edit-accuracy bench (same machine, same Chrome, both arms):

• main: 4.4% of drag frames over 8 ms of main-thread work; the selection chrome costs 0.18 ms per pointer move (1.8% of frame work), and removing it from the traced frames over 8 ms brings none of them under 8 ms.
• main plus this change: 7.0% of frames over 8 ms. Chrome restyles 32 elements per move instead of 11 (33 instead of 16 on resize), because every handle reads the four wrapper variables that now change on each move. Crop and rotate are unchanged, as a control.
  The second half would keep writing those variables on every move, so it can't recover the cost. The frame time over 8 ms is elsewhere (React and gesture code, about 2.7 ms per move).