fix(webkit): place overlay panels with translate so re-anchors can transition

[gabriel-lisboa-azion]

Three fixes to usePlacement, all about a panel that moves after it is already up.

1. Placed with translate, not top/left

Two reasons:

• A translate is a compositor property, so re-anchoring an open panel can be transitioned into place instead of snapping a layout property.
• translate is a property of its own, so it composes with the transform: scale(...) the open/close keyframes animate. A transform: translate3d(...) here would overwrite them.

Note the transition names translate, not transform — in Tailwind v4 the translate utilities compile to the standalone translate property, so a transition-[transform] would animate nothing, silently (.claude/rules/styling.md).

2. anchored gates that transition

It turns true one frame after the opening placements land, so the entrance stays the panel's own scale animation and only later re-anchors glide. Without the gate a panel would visibly travel in from the off-screen seed.

It resets on close, but the panel is deliberately not moved off-screen there — it is still in the DOM playing its leave animation, and moving it would replace that animation with a disappearance.

3. Measured with offsetWidth, not getBoundingClientRect

getBoundingClientRect reports the transformed box, and the panel opens under scale(0.9) → scale(1). Read mid-animation it was up to 10% narrow, which placed a centred tooltip 4.1px off its trigger — and left it there, because nothing re-measured afterwards.

offsetWidth/offsetHeight are the layout box, so placement no longer depends on which frame of the entrance it is read on.

4. A ResizeObserver re-anchors an open panel whose content resizes

A centred panel's position is computed from its measured width, so a panel that resizes after placement keeps coordinates for the width it used to have. Nothing else catches this: the window has not resized and the page has not scrolled.

Measured on the copy control, whose tooltip swaps Copy code for Copied while the pointer is still on it — the panel lost 21px of width, slid 4px, and ended 10.4px off centre in a single frame. Reads as a glitch, and the same applies to any overlay whose content changes while it is up.

Safe from feedback: a transform does not affect the observed box, and updatePosition only writes position.

---

⚠️ #891 is preserved — this is a merge, not a cherry-pick

#891 (stop re-anchoring the popover panel when its own content scrolls) landed on main after this work started and touches the same two files. Naively replaying this branch would have reverted it.

Verified with a real 3-way merge (git merge-file against the merge base):

• use-placement/index.js — the only conflict is the comment. The guard code is character-identical on both sides:

  const target = /** @type {Node | null} */ (event?.target ?? null)
  if (target && panelRef.value?.contains(target)) return

  The comment kept here is a superset: it retains fix(webkit): stop re-anchoring the popover panel when its own content scrolls #891's capture-phase rationale and adds why repositioning on an inner scroll also cost two bounding rects and an inline-style write per scrolled frame.

• popover.test.ts — also comment-only. Test-name sets on both sides are identical (comm diff empty in both directions), so fix(webkit): stop re-anchoring the popover panel when its own content scrolls #891's does not re-measure the trigger when the panel scrolls, but does when the page does regression test survives intact.

Also

• tooltip.vue consumes anchored via data-anchored, with motion-reduce:transition-none.
• .specs/tooltip.md records the re-anchor motion row and the measurements.