xlsx-win v2: UI-Automation modal-dialog detection + screenshot capture (parked, pending evidence of need)

[dachent]

Parent: #33
RFC: #32, amended by RFC 0002
Split out from: #72

Why this is parked, not just deferred

RFC 0002 decision 7 already made dialog handling prevention-first: DisplayAlerts=False, AskToUpdateLinks=False, AutomationSecurity=msoAutomationSecurityForceDisable, Workbooks.Open(..., UpdateLinks:=0) -- shipped in #36, confirmed working via DialogPreventionTests' real COM-readback verification. UI-Automation/WinEvent modal-dialog detection + screenshot capture was always scoped as the fallback for what prevention can't cover (RFC 0002 decision 7 itself: "prevention-first... detection as fallback, not primary").

As of this issue, no fault injection across #36 or #39 -- worker crash, invalid manifest, hanging worker/forced kill, or a real Power Query refresh against a genuine production workbook with 10 live connections -- has produced a single case where an actual unhandled modal dialog blocked a job. The one real failure mode found and fixed (Excel not exiting after a Power Query refresh, see #36/#39) turned out to be an unrelated COM-reference-lifetime bug, not a dialog.

Building the full UI-Automation + WinEvent hook + dialog classification + screenshot-capture system now would be real, nontrivial infrastructure (comparable in scope to #36 itself) built against a failure mode that hasn't actually been observed. Parking it rather than building it speculatively.

Trigger to pick this up

Any of the following is sufficient evidence to stop parking this and build it:

• A real job (certification corpus, real-world validation, or actual use) hangs at a phase-deadline timeout where the supervisor's event log or process inspection shows Excel waiting on a dialog -- not a slow refresh, not a slow process-exit -- i.e. a genuine repeat of the class of problem RFC 0001 originally worried about.
• A workbook requiring a credential prompt, a "keep this format" save dialog, an "external data" trust prompt, or any other modal that prevention-first's four COM properties don't cover is actually encountered in real use.
• The maintainer decides to proactively harden against this class of failure ahead of an actual incident, as a deliberate risk-acceptance change rather than an evidence-driven one.

Scope (when picked up)

• UI-Automation or WinEvent-based detection of a modal window owned by the tracked Excel process.
• Classification of known dialog types where feasible (e.g. by window class/title), fail-closed (unknown dialog = fail loud, don't guess) for anything unrecognized.
• Screenshot + window-text capture on detection, attached to the job's failure evidence.
• A normalized error code (e.g. UNEXPECTED_MODAL_DIALOG) distinct from PHASE_DEADLINE_EXCEEDED, so a caller can tell "timed out because of a dialog" from "timed out because work was genuinely slow."

Acceptance criteria (when picked up)

• A job artificially blocked by a real modal dialog (test harness triggers one deliberately -- e.g. a workbook requiring a save-format prompt, or a locked file) is detected within a bounded time, not left to run out the full phase deadline.
• The captured screenshot/window text is sufficient for a human to identify which dialog blocked the job, from the artifact alone.
• No regression to the existing PID-scoped, never-by-name kill discipline.