Bound every wait before the overlay is interactive

Running wl-pick twice left the second instance hung with no window at all
and no way to end it but kill.

The hang was in the capture phase, not the overlay. sway answers a capture
request for a toplevel that another client is already capturing with
silence: no frame, no failed, no stopped. captures_settled() waits for every
tile to reach one of those three, so it waited forever, holding its buffers,
having never created a layer surface. Any concurrent capture client will do
this, not just a second wl-pick.

So the phases before the overlay is interactive now have a deadline. pump_for
polls the connection with one, and a tile that never arrives is drawn as a
bare label, exactly as an outright capture failure already was.
report_unsettled names those tiles on stderr, which is the diagnostic whose
absence made this hard to find.

The first instance had a second problem: sway hands the keyboard to the new
overlay and sends the old one wl_keyboard.leave, but the dispatcher only
handled Key, so the loser sat on screen holding a grab it no longer had,
deaf to every key. That is the process that stays around. Losing the grab
for good now ends the run, so a second wl-pick started from the same
keybinding replaces the first rather than stranding it.

For good, because sway also sends leave followed immediately by enter on the
same surface -- microseconds apart -- as a focus refresh when the pointer
crosses the overlay. Treating a bare leave as terminal made a lone instance
quit itself after less than a second. Focus is tracked in the dispatcher and
the main loop only gives up once it has failed to come back.

pump had no callers left after that: every wait is now either budgeted or
focus-aware.

README.md

@@ -91,6 +91,16 @@ chooser_type=simple
 chooser_cmd=wl-pick --format portal
 ```
 
+**Starting a second wl-pick replaces the first.** The new overlay takes the
+keyboard grab, and the one that loses it exits without printing anything — so
+hitting the keybinding twice leaves you with one overlay, not a stranded
+process. The catch is that sway answers a capture request for a toplevel
+another client is already capturing with silence — no frame, no failure — so
+the replacement's thumbnails are mostly blank until the first instance has
+gone. Every wait before the overlay is interactive is capped at two seconds
+for that reason: a tile that never arrives is drawn as a bare label, and the
+grid still works.
+
 | key | |
 |---|---|
 | `→` `←` / `l` `h` / `Tab` `Shift+Tab` | next / previous tile |