MultiSelect custom printable navigation keys move cursor while filtering

Description

Describe the bug

When a printable character is configured as a MultiSelect navigation key, pressing that key while filtering updates both the filter input and the selection cursor.

For example, if "a" is added to MultiSelect.Down, typing "a" into the filter also moves the cursor down.

The current implementation special-cases the default "j" / "k" bindings while filtering, so custom printable bindings are not handled.

Reproduction

keymap := huh.NewDefaultKeyMap()
keymap.MultiSelect.Down.SetKeys("down", "a", "ctrl+n")

m := huh.NewMultiSelect[string]().
    Options(
        huh.NewOption("alpha", "alpha"),
        huh.NewOption("bravo", "bravo"),
    )

m.WithKeyMap(keymap)
m.Filtering(true)

msg := tea.KeyPressMsg(tea.Key{
    Code: 'a',
    Text: "a",
})

_, _ = m.Update(msg)

Before the key press, the hovered option is "alpha". After pressing "a", the hovered option becomes "bravo", even though "a" is being entered into the filter.

Expected behavior While filtering, printable key events should be handled as text input without also triggering navigation actions. Non-printable navigation bindings such as arrow keys or ctrl+n / ctrl+p should continue to work.

Notes

There are existing FIXME comments around the j / k checks in field_multiselect.go mentioning that the keymap should be respected. I tested replacing the hardcoded checks with a printable-text check using msg.Key().Text, and the reproduction above no longer moves the cursor.

One possible direction would be to separate field key dispatch from filter updates. While filtering, printable key events could bypass field key dispatch but still continue through the filter update/recomputation path. This would remove the need for individual j/k checks and keep the responsibilities more explicit.

I'm happy to open a PR with a regression test if this approach looks appropriate. @andrinoff would you mind taking a look at the proposed direction here?