fix(tui): accept macOS Option-key chars for file picker toggles

[Sayt-0]

Summary

The file picker alt+h / alt+i visibility toggles never fire on macOS. The OS substitutes a Unicode character for Option+key at the input-system level before the terminal receives the event, so msg.String() returns the substituted character instead of alt+h / alt+i.

This implements Option B from #2611: keep alt+h / alt+i as the primary bindings and accept the macOS-produced characters as aliases. Addresses #2611.

Change

Area	Before	After
Binding storage	inline msg.String() == "alt+h" checks	filePickerKeyMap struct (mirrors costDialogKeyMap)
Toggle hidden	alt+h only	alt+h and ˙ (U+02D9, macOS Option+H)
Toggle ignored	alt+i only	alt+i and ˆ (U+02C6, macOS Option+I)
Matching	string compare	key.Matches

Issue expectations mapped

Expectation from #2611	Status
Keep alt+h / alt+i working (Linux, "Option as Meta" enabled)	yes, primary bindings unchanged
Accept the macOS-substituted chars as aliases	yes, U+02D9 / U+02C6 added
Follow the existing key.NewBinding / keymap style	yes, filePickerKeyMap + defaultFilePickerKeyMap()
Backward compatible, low risk	yes, additive only

Known limitations (as noted in the issue's Option B section)

• Covers the standard US and US-International layouts only. Other national layouts emit different Unicode characters for Option+H / Option+I and are not handled.
• ˆ (U+02C6) is a dead key on macOS, so Option+I may compose with the next keystroke rather than arrive as a standalone press in some terminals.
• Option A (modifier-free keys such as . and !) remains the cleaner long-term fix and is independent of this change. Option B is the low-risk patch the issue proposed to apply immediately while Option A is discussed.

Tests

• TestFilePickerToggleHiddenViaMacOSOptionChar and TestFilePickerToggleIgnoredViaMacOSOptionChar simulate the macOS KeyPressMsg and assert the toggles fire.
• The existing alt+h / alt+i tests continue to pass.
• The new tests assert against the KeyPressMsg the issue documents macOS producing (Text set to U+02D9 / U+02C6); they exercise the binding wiring, not a hardware-captured event. Removing the aliases makes the new tests fail while the alt+h / alt+i tests still pass, confirming they are genuine regression guards.

Validation

go build ./..., gofmt, go vet, golangci-lint (0 issues), and the full pkg/tui/dialog test suite pass.

[docker-agent]

Assessment: 🟢 APPROVE

The changes look correct and well-structured. The filePickerKeyMap struct and defaultFilePickerKeyMap() constructor follow the existing keymap pattern. The Unicode code points U+02D9 (˙) for Option+H and U+02C6 (ˆ) for Option+I are correct for macOS US/US-International layouts, and the switch from direct msg.String() comparisons to key.Matches is the right approach. Both the production code and the tests are sound — no bugs introduced by this PR.