Reduce the synthesized resize to the bottom-right grip only

The handles are invisible and paint above the frame, so the north strip ran the
full window width across the caption buttons and the north-east square sat on
the close button's own top-right corner. Crossing one dropped that button's
:hover mid-glow, which reads as the Aero glow flickering or sticking — an
artifact with nothing wrong in the CSS at all.

Only the bottom-right corner overlaps nothing: it lands in the 6px gutter that
.window-body's margin leaves below and right of the content. That is also where
Win7 put its own resize gripper, so one grip is the more faithful answer anyway.
Bumped to 1rem from 0.75rem since it is now the only way to resize.

resizeFrame stays general and the probe still exercises all eight edges: the
origin-moving cases are the subtle ones and are worth keeping proven, so
restoring a side later is one entry in the component against tested math. Both
the component and gotchas.md now spell out which edges are safe to restore
(south, east, west) and which are not (north and both top corners).

Harness diffs 0; math, hover and menu probes clean.

Co-Authored-By: Claude <noreply@anthropic.com>

docs/gotchas.md

@@ -269,11 +269,21 @@ touching the adjacent code.
 - **A frameless window cannot be resized, and `preventDefault` will not save
   you from the drag region.** Undecorating the GTK window (what
   `titleBarStyle: "hidden"` does) takes the WM's resize borders with it, and
-  electrobun exposes no resize gesture — hence the synthesized handles in
+  electrobun exposes no resize gesture — hence the synthesized grip in
   `ui/src/app/skins/7like/window-resize/` (a STOPGAP; that file carries the
   removal checklist, and `scripts/check-electrobun-resize.ts` fires from
-  `postinstall` when upstream makes it deletable). Three traps live in that
-  code, all verified against `dist/api/bun/preload/dragRegions.ts`:
+  `postinstall` when upstream makes it deletable).
+  **An invisible resize handle over a control steals that control's hover.** A
+  full eight-handle set shipped briefly and was reverted: the north strip ran
+  the whole width across the caption buttons and the north-east square sat on
+  the close button's corner, so crossing one dropped the button's `:hover`
+  mid-glow and looked like a rendering artifact in 7.css — nothing in the CSS
+  was wrong. Only the bottom-right corner overlaps nothing (it lands in the 6px
+  gutter `.window-body { margin: 0 6px 6px }` leaves). Any new handle must be
+  checked against what sits under it; south/east/west are innocent, north and
+  both top corners are not.
+  Three more traps live in that code, all verified against
+  `dist/api/bun/preload/dragRegions.ts`:
   - It starts a window **move** from a `mousedown` listener on `document`, in
     the **bubble** phase. It never reads `defaultPrevented`, so
     `event.preventDefault()` does **nothing** to stop it.