fix(dialog): the Windows picker takes the keyboard, not just the z-order

[danyaberezun]

Follow-up to #141 (merged). The dialog now opens in front of the browser, but without focus — you have to click it before typing or arrowing around.

Why top-most wasn't enough

TopMost wins the z-order; it doesn't make the window active. The browser stays the foreground window, so the folder dialog opens on top of it with no keyboard.

SetForegroundWindow is blocked by the same foreground lock that put the dialog behind the browser to begin with — a process that isn't already foreground can't just take it. The documented way past it is to attach our input thread to the current foreground thread first:

$fg = GetWindowThreadProcessId(GetForegroundWindow(), $null)
$me = GetCurrentThreadId()
AttachThreadInput($me, $fg, $true)
SetForegroundWindow($owner.Handle)
AttachThreadInput($me, $fg, $false)

Best-effort, in a try/catch: a host that can't compile the P/Invoke (ConstrainedLanguage, no compiler) still gets the top-most dialog — just unfocused, as today — rather than no dialog at all.

-Command → -EncodedCommand

That block needs C# string literals, and quoting embedded double quotes through a Windows command line into PowerShell's own parser is exactly the minefield apps/cli/src/powershell.ts documents and avoids with a temp .ps1. The script now travels as -EncodedCommand (base64 UTF-16LE): one quote-proof argv element, no temp file to write or clean up. Newlines come free with it, so the script reads as a script instead of a ;-joined one-liner.

Verified on Windows 11

Measured on a real Windows 11 host, driving selectDirectory() from a background Bun process with an unrelated app holding the foreground — the same conditions that make the bug visible:

	dialog visible	focused	keyboard
main (#141, top-most owner only)	yes	no — 3/3 runs	goes to the browser
this PR	yes	yes — 3/3 runs	goes to the dialog

Focus was read with GetForegroundWindow() against the dialog's hwnd, filtered to a live picker process (so windows left behind by earlier runs can't be mistaken for a fresh one). Keyboard delivery was checked end to end, not just inferred from the focus flag: {ENTER} sent to no particular window returned the highlighted folder ({"path":"C:\Users\danya\Desktop"}), and {ESC} returned {"path":null} at exit 0 — cancel still reads as cancel, not as a failure.

Also green: typecheck, lint, unit tests (10/10 in the dialog suite), and — from #141's run — 115/115 e2e on Linux.

Scope

Three files. The two source files, plus dialog/SPEC.md — taking you up on the offer in the last revision: the spec had credited the invisible top-most owner for getting the picker in front, which the table above shows isn't what does it. It now records the foreground lock, both measurements, and that the grab is best-effort by design, so the next person doesn't re-derive it from the P/Invoke.

The unit test decodes the base64 payload before asserting on the script, and pins AttachThreadInput / SetForegroundWindow($owner.Handle), the paired attach/detach (a stuck attachment would hand us another app's keyboard state for as long as the picker lives), and the catch that keeps the grab optional.

[jetbrains-air]

Approved — ready to merge.

[jetbrains-air]

Approved — ready to merge.