test(nix): the ring of wallpaper is read outside the frame

A port whose test window has a color of its own put it in the ring, and
a warm ring beside a cool window read as mixed. Both ports draw the
border outside the frame, so what is inside it is not read. The fake
leaves room for the ring and follows focus-workspace. BEHAVIOUR.md says
what kfw's next has fixed or found since: the maximize, the killed
daemon, and the top edge.

docs/dev/BEHAVIOUR.md

@@ -261,24 +261,27 @@ counts when it needs them and asks only that the monitor it left shows a workspa
 Windows runs on `next` (komorebi `6d862a11`), with the decision of what to do with each:
 
 - **A window the user maximizes** (`maximizing.user`, the title bar button). kfde takes it as the
-  workspace's maximized window, as for `toggle-maximize`; kfw sets `maximized_window` only from
-  `toggle-maximize`, nothing turns a user's maximize into it, so every later check of the scenario
-  fails on Windows. **Decided: a known difference for now**, neither port changes; the Windows runner
-  records it as a known failure.
+  workspace's maximized window, as for `toggle-maximize`. kfw's `next` (aa353a71) does too now, and
+  the first checks pass. What differs is what the layout commands do while it is maximized: kfde
+  ignores them all, and kfw, with a window the user maximized, still ignores `move`, `cycle-move`,
+  `promote` and `unstack`, but `stack left/right` stacks the other windows (two containers become
+  one) and `toggle-float` floats the window and ends the maximize. **Which is the reference is a
+  decision, with the maintainer**; the scenario stays as it is and the Windows runner records the
+  rest as known failures.
 - **A window moved to another display by something other than a drag** (`hotplug.user_move`,
   `SetWindowPos` on Windows). kfde follows the window to the other monitor; kfw relocates a window
   only when a drag ends (`MoveResizeEnd`) and a move by any other means raises no such event, so it
   is not taken there within 45 s. **Decided: a known difference for now**, recorded as a known
   failure on Windows.
 - **A killed daemon** (`lifecycle_hidden.crash`). On kfw, after `kill -9` during a monocle the windows
-  it cloaked stay cloaked and unmanaged, at their old frames, and the next daemon manages only the
-  windows that were in view: a clean `stop` uncloaks them, a kill does not, and a starting daemon
-  does not look for cloaked windows. On KDE it passes (the next start sweeps the parking desktop).
-  Looks like a kfw bug, with the kfw session's user.
-- **Dragging the top edge of the lower tile up** (`resize.edge_cases`, `win3:top:0,-72`). On kfw
-  nothing moves, while the same shared edge dragged from the other tile (`win2:bottom:0,72`) moves
-  by what the pointer did; the other seven drags pass. Looks like a kfw bug, with the kfw session's
-  user. (On KDE all of them pass.)
+  it cloaked stayed cloaked and unmanaged. Fixed on kfw's `next` (dc9b2e95, uncloaks what a killed
+  daemon left): it passes 17/0 there. On KDE it passes (the next start sweeps the parking desktop).
+- **Dragging the top edge of the lower tile up** (`resize.edge_cases`, `win3:top:0,-72`). Not a kfw
+  bug: the scenario pressed 4 px outside the frame, and a Windows window has no invisible border on
+  its top, so the press hit the desktop. `Platform.resize_grab` gives each port its own press point
+  (KDE outside the frame, Windows 2 px inside the top row); it passes 18/0 on both ports. On kfw
+  the scenario is still occasionally flaky (a frame that lags its tile): it now waits for the frames
+  to match the layout before each press.
 
 ## What the scenarios had to allow for