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/architecture.md

@@ -483,12 +483,16 @@ lights to reserve `pl-24` for.
 
 **Window resize (STOPGAP)**: undecorating the window also removes the WM's
 resize borders, and electrobun 1.18.1 has no native resize gesture — so
-`skins/7like/window-resize/` synthesizes one: eight handles overlaying the frame
-drag it through `windowGetFrame`/`windowSetFrame` → `BrowserWindow.setFrame`.
+`skins/7like/window-resize/` synthesizes one: a bottom-right grip drags the
+frame through `windowGetFrame`/`windowSetFrame` → `BrowserWindow.setFrame`.
 Mounted by all three win7 roots, hidden while maximized by a CSS `:has()` rule
-(no second `windowState` subscription), and every handle carries
+(no second `windowState` subscription), and the grip carries
 `electrobun-webkit-app-region-no-drag` or the drag region would move the window
-instead. The frame math is a dependency-free module so
+instead. **One corner, not eight handles**: the handles are invisible and paint
+above the frame, so a north strip or top corner overlays the caption buttons and
+steals their `:hover`, which reads as the Aero glow flickering on those buttons.
+The bottom-right corner is the only one that overlaps nothing (it sits in the
+6px gutter `.window-body`'s margin leaves). The frame math is a dependency-free module so
 `scripts/resize-math-probe.ts` can assert all eight edges without a window.
 **This is meant to be deleted**: the component header carries the removal
 checklist and `scripts/check-electrobun-resize.ts` (wired into `postinstall`)

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.

docs/platform-notes.md

@@ -44,8 +44,10 @@ counterpart, does not link `gtk_window_begin_resize_drag`, and `BrowserWindow`
 has neither `setResizable` nor min-size constructor options. The window is still
 *programmatically* resizable (`setFrame`/`getFrame` work, and
 `gtk_window_set_resizable(false)` is never called), so the app **synthesizes the
-input affordance**: eight handles in the webview drag the native frame over RPC
-(`ui/src/app/skins/7like/window-resize/`).
+input affordance**: a bottom-right grip in the webview drags the native frame
+over RPC (`ui/src/app/skins/7like/window-resize/`). Only that one corner — an
+invisible handle anywhere else overlays a control and steals its hover, which is
+what a full edge set did to the caption buttons.
 
 That is a **stopgap** — each drag tick is an RPC hop plus an FFI call, where a
 real WM grab is compositor-side. `scripts/check-electrobun-resize.ts` watches the