feat(screen): share the container's screen in a browser, driving nothing

[theophile-wallez]

Stacked on #6 — its commit is the first of the five here and disappears from this
diff when #6 merges.

The report

login --web showed a black page with everything apparently running.

Why it was black

1. A login session from an earlier hour was still alive and owned intune-portal
   on its own display, :77.
2. The new --web run made :78 and asked the container to start the portal.
3. intune-portal is a single instance. The second launch handed its request to
   the process on :77 and exited, so :78 never had a window on it.
4. The viewer streamed an empty display: a black 1280×800 rectangle.
5. portal_is_running greps the process name, so it found the old portal and
   reported the portal as up. Nothing in the page said otherwise.

What is here

screen, a new command. It streams; it does not sign in. It starts the portal so
the first Intune screen is there without a second command, and from that point it
touches nothing: the portal, the broker's Authentication dialog and an Edge window
all appear as they are, and the reader drives them. login is unchanged.

It looks for a display before it makes one — a display in this tool's range that
already has a window is the one it shares — so case 3 above streams the portal that
exists instead of an empty screen. A share that finds a display leaves it running;
only a share that opened one closes it. A portal running with no display is
closed first, because it is unreachable and would otherwise absorb the next launch.

The viewer sends the windows, not the display. A 478×628 portal on a 1280×800
screen meant two thirds of the page was undrawn desktop. It now sends the union of
the mapped windows, read from the X geometry rather than from a brightness scan, so a
dark-themed window is not cropped to its light part. The picture therefore changes
size mid-session: the canvas takes its size from each answer, and a click is put back
on the display by the box's origin before XTEST sees it.

A screen with nothing on it says so on the picture. The status line already said
it, but it is one line under a large black rectangle.

Two fixes underneath.

• portal_stop now waits for the exit. It sent TERM and returned, so the detach that
  follows saw a GUI app running and skipped — which is why a machine was found
  reporting Display fwd: on (GUI session active) for a session that had ended. It
  is also what makes the close-then-start above reach a container with no instance.
• Xvfb::start takes the next display number when another process wins the race
  between finding a free one and starting a server on it. Two screen shares started in
  the same second race exactly like that; two X11 tests run together already did, and
  failed about half the time. Nothing is matched against Xvfb's text — the number
  being taken now, having been free a moment ago, is the signal. The failure message
  also stopped quoting the xkbcomp keysym warnings Xvfb opens with and now carries the
  error line.
• Placing and focusing a window no longer refuses a keystroke when it fails: there is
  no window manager, so the call races the window it names.

Tested

• cargo test --lib: 89 passed. cargo fmt --check and
  cargo clippy --all-targets -- -W clippy::all: clean.
• The two X11 end-to-end tests pass together, five runs in a row — they could not be
  run together at all before the Xvfb fix.
• Every one of the five commits builds on its own.
• Against the real container on a headless host: screen streams the Intune Agent
  first screen at 478×628; a click on Sign in sent from the browser reaches the
  portal and starts the identity broker; a second screen shares the first one's
  display instead of showing black, and leaves it running when it closes; a stale
  portal with a dead display is recovered; Finish closes the portal, drops the
  display and returns the container to headless.