windows: handle GHOSTTY_ACTION_SELECTION_CHANGED → fire UIA TextSelectionChanged #550

Context

The 2026-06 upstream sync (windows rebased onto ghostty-org/ghostty 5e872a6a6) added a new apprt action the C# app binds but does not yet handle:

• Upstream: core: send selection_changed notification ghostty-org/ghostty#12902 (core: send selection_changed notification, c4e1ab888)
• New enum value GHOSTTY_ACTION_SELECTION_CHANGED in include/ghostty.h (payload-less; fired on a selection state transition in src/Surface.zig).
• macOS consumes it to post NSAccessibility .selectedTextChanged (macos/.../SurfaceView_AppKit.swift). GTK currently no-ops it.

Why it matters

This ties directly into the UIA text provider that just landed (#542–#545). Today the C# UIA layer has no push signal when the terminal selection changes, so assistive tech isn't notified. The Windows-native equivalent of macOS's .selectedTextChanged is raising the UIA TextPatternIdentifiers.TextSelectionChangedEvent from the terminal automation peer.

Suggested work

• Add SELECTION_CHANGED to the action dispatch — windows/Ghostty.Core/Interop/GhosttyActions.cs + windows/Ghostty.Core/Input/ApprtActionMap.cs.
• On receipt, read the current selection (existing ghostty_surface_has_selection / SelectionRange.cs plumbing) and raise TextSelectionChangedEvent from windows/Ghostty/Accessibility/TerminalAutomationPeer.cs.
• Debounce/coalesce if the action fires rapidly during drag-select.
• Smoke test under Narrator / an automation client that the event fires on select + clear.

References

• apprt action plumbing: src/apprt/action.zig, include/ghostty.h (GHOSTTY_ACTION_SELECTION_CHANGED)
• macOS consumer (reference impl): macos/Sources/Ghostty/Surface View/SurfaceView_AppKit.swift

Surfaced during the 2026-06-25 upstream sync.