fix: keep the system print dialog in front of the window that rendered it

The render helper sat on top of the Print dialog, so the dialog could
not be reached and nothing could be printed.

Two causes. The daemon could not see window titles at all — the tree
walk never collected them — and both windows arrive close enough
together to be configured in the same pass, in whatever order the tree
lists them. Configuring a window focuses it, so whichever was done last
ended up in front, and that was not reliably the dialog.

The dialog is now recognised by its exact title and configured last, and
if a Chrome popup takes focus while it exists, focus is handed straight
back. Focus is only ever reclaimed from another popup: clicking the main
browser or the dock is the teacher's business and is left alone.

A title match, narrowly, and only for this one known dialog. Creation
order still decides which Chrome window is the browser; nothing else is
classified by what it happens to be called.

Nothing auto-closes the helper. After Print is cancelled it stays, and
the sticky dock X still closes it.

Proven by looking rather than by state. The render window is given a
saturated background in the fixture so a screenshot answers "which
window is in front" unambiguously: Print opens in front, the helper is
then deliberately raised over it and Print comes back in front,
cancelling Print leaves the helper visible with the dock X still
offering it, and that X closes exactly the helper and leaves the main
browser untouched.

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

VERSION

@@ -1 +1 @@
-0.1.43
+0.1.44