dialog: Reclaim focus when it escapes the topmost modal (#2828)

## Summary

`Root::open_dialog` focuses the dialog when it opens, but that is the
only moment the modal claims focus. Anything that runs afterwards can
move focus outside the host — in Longbridge, each workspace layout load
ends with a deferred "focus the active workspace", which lands after a
confirmation dialog opened during startup and silently steals its focus.

With focus outside the host, the dialog is dead to input: the footer
buttons deliver `Confirm`/`Cancel` through `window.dispatch_action`,
which dispatches along the focused path, so the actions never reach the
host's `on_action` handlers (`Button` intentionally prevents
focus-on-mouse-down, so clicking a button does not bring focus back
either); the `escape`/`enter` bindings lose their `Dialog` key context
the same way. Clicking the backdrop happened to re-focus the host via
its `track_focus` mouse-down — which is why "click the backdrop first,
then the button works" was the observed workaround.

Reclaim focus during render whenever the topmost open dialog no longer
contains the window focus. The `topmost` guard keeps stacked dialogs
from fighting over focus, and anything opened from within the dialog
(inputs, in-tree popups) stays inside `contains_focused`, so it is
unaffected. Reclaiming rather than dismissing fits the confirm-dialog
use case: the user has not answered yet.

## Test Plan

- Verified end-to-end in the Longbridge desktop app with an instrumented
build: a workspace-upgrade confirm dialog opened during startup. Before
this change, `is_action_available(&Confirm)` was `false` at click time
and the click was silently dropped; after it, the first click delivers
`Confirm` to the host and the dialog closes.
- `cargo test -p gpui-base --lib` — 568 passed.

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>