fix: keep the dock's Close button reachable

The Close button followed focus, and moving the pointer down to the dock
moves focus off the popup. So the button disappeared somewhere on the
journey to it, and a secondary Chrome window could not be closed with a
mouse at all. Found on the endpoint; my fault.

The target is remembered instead. Once a secondary window has been
focused the dock keeps offering to close it, and losing focus — to the
dock, the main browser, a print dialog, any layer-shell surface —
changes nothing. It moves on only when that window closes or another
secondary takes over, and it falls back to another open secondary rather
than to nothing, so cancelling a print dialog leaves the render window
still closeable. It is chosen from the secondary list, which never
contains the first window, so it can never name the main browser.

Restoring the floating role to a window that already existed no longer
moves or focuses it. Moving it would undo wherever the teacher dragged
it; focusing it would raise the render window over the print dialog
sitting above it, which is one way the print flow was getting disturbed.

Verified by driving a real pointer through the exact path that was
broken: pointer over the popup, click to focus, then travel down to the
dock in steps, screenshotting throughout. The button is still there on
arrival, at 992,1041. Then the print flow: main browser, render window
and a separate Print dialog, pointer to the dock, button still there,
and killing the dialog leaves the render window as the new target with
the main browser untouched.

The button's own action could not be actuated in that harness, because
synthetic pointer input does not reach Wayland clients under headless
sway — the Browser button does not respond to it either. The action was
run directly instead, closing exactly the remembered container and
leaving main Chrome alive.

Co-Authored-By: Claude Opus 5 <[email protected]>

docs/browser.md

@@ -142,9 +142,29 @@ polling, so dragging a popup costs nothing.
 
 ### Closing one
 
-The Close button is **in the dock**, and only while a secondary window
-is focused. Clicking it runs `[con_id=N] kill` on that exact container:
-never the main browser, never a Chrome process.
+The Close button is **in the dock**, and it is **sticky**. Once a
+secondary window has been focused, the dock keeps offering to close it
+until that window goes away.
+
+That stickiness is the whole design. It first followed focus, which made
+the button impossible to click: moving the pointer down to the dock
+moves focus off the popup, so the button vanished somewhere on the way
+to it. Nobody could ever reach it.
+
+The remembered target changes only when:
+
+- the window it names closes — and it then falls back to another
+  secondary that is still open, so cancelling a print dialog leaves the
+  render window still closeable; or
+- another secondary window is focused and takes over.
+
+Focus moving to the dock, the main browser, a print dialog or any
+layer-shell surface changes nothing. The target can never be the main
+browser: it is chosen from the secondary list, which never contains the
+first window.
+
+Clicking it runs `[con_id=N] kill` on that exact container: never the
+main browser, never a Chrome process.
 
 An earlier attempt anchored a close button to the popup's own corner as
 a separate layer-shell surface. On real hardware it chased the window