fix(web): restore renderer focus after preview presses

[0bkevin]

Preview key presses can leave the host renderer with a connected preview control focused after native focus returns, so the next composer keystroke is lost. This keeps the existing void IPC contract and restores the prior DOM focus only when the document is still focused, the element remains connected, and no newer user focus took ownership.

The change is limited to the web renderer:

• Wrap the existing preview press bridge call with a DOM focus guard.
• Recognize native focus transfer separately from newer pointer, keyboard, or programmatic DOM focus.
• Keep overlapping calls concurrent while preventing an older call from reclaiming focus.
• Preserve the operation result or rejection when focus restoration fails.

PreviewAutomationHosts is mounted only in Electron (isElectron && previewBridge.automation), so the standalone browser path is unaffected. This is the renderer portion of #9530 and is independent of the desktop native companion PR.

Validation:

• 10 focused renderer focus tests passed.
• @t3tools/web typecheck passed.
• Targeted lint passed with the existing warning at PreviewAutomationHosts.tsx:741.
• Modeled baseline test failed before the guard and passed with it.
• No live Electron before/after recording is included yet; the draft remains pending that runtime evidence.
• During overlaps, the latest-call guard conservatively suppresses stale restoration; this does not claim to resolve every cross-thread focus race.

Refs #5792. Replaces the renderer portion of #9530. Desktop companion: #9848.

Model: GPT-5.6 Luna implementation; GPT-6 review
Harness: Codex in T3 Code

[juliusmarminge]

Superseded by #11354 (fix(desktop): keep preview keystrokes out of the composer), which landed the desktop-side fix for preview automation leaking into the composer (Refs #5792). Closing this renderer focus-restore companion as wash leftover hygiene — reopen if anything unique still needs merging.