Don't cancel renames or dismiss Go to Line when the window is deactivated (#61852) (cherry-pick to preview)

[zed-zippy]

Cherry-pick of #61852 to preview

---

Closes #39286

Problem

Switching the keyboard layout on Wayland (e.g. GNOME's Super+Space)
makes the compositor briefly grab the keyboard, which deactivates the
Zed window. GPUI reports window deactivation as a blur of the focused
element (WindowFocusEvent is emitted with an empty
current_focus_path), so controls that dismiss or cancel on blur
treated it as the user abandoning them. The same happens when switching
to another app window. As discussed in #39286 with @MrSubidubi, the
desired behavior is to keep these controls open and focused across
window deactivation.

Fix

Guard the blur-driven cancel/dismiss handlers with
window.is_window_active(), following the pattern established for
pickers in #41320:

• Project panel: in-progress rename / new file / new directory inputs
  are no longer cancelled when the window is deactivated
• Collab panel: in-progress channel rename is no longer cancelled
• Go to Line: the dialog is no longer dismissed

In-window focus changes (clicking elsewhere, Escape) keep the existing
commit/cancel semantics. The terminal tab rename needed no change: it
re-checks FocusHandle::is_focused, which reads window.focus and that
survives deactivation. Command palette, file finder, and outline were
already fixed by #41320.

Added a regression test (test_rename_survives_window_deactivation)
that starts a rename, deactivates the window via the test platform, and
asserts the edit state survives.

Two milder siblings were left unchanged to keep this PR focused,
flagging them for a maintainer decision: the notebook markdown cell
exits edit mode on blur (crates/repl/src/notebook/cell.rs), and the
diagnostics view prunes diagnosticless buffers on blur
(crates/diagnostics/src/diagnostics.rs).

Longer term it may be worth carrying the blur cause in the event itself
(e.g. a FocusMoved vs WindowDeactivated reason on FocusOutEvent
and EditorEvent::Blurred), so each handler has to state which causes
it handles instead of relying on an opt-in guard; happy to file a
separate issue for that.

Before

before.mp4

After

after.mp4

Suggested .rules additions

Handlers that cancel or dismiss UI on blur (EditorEvent::Blurred,
on_blur, on_focus_out) must check window.is_window_active() first:
GPUI reports window deactivation (app switch, layout switcher grabbing
the keyboard) as a blur of the focused element, and dismissing there
loses user input.

Release Notes:

• Fixed in-progress file renames, channel renames, and the Go to Line
  dialog being cancelled when the window is deactivated, e.g. by a
  keyboard layout switch on Wayland or by switching to another application
  (#39286).

---

Co-authored-by: MrSubidubi finn@zed.dev