fix: pass fish_key_bindings to prompt subshell

[mzilinski]

Summary

The async prompt subshell in fish_prompt.fish receives fish_bind_mode but not fish_key_bindings. When fish_key_bindings is set globally (not universally) in the parent shell — which is the case on distros like CachyOS that set it via config.fish — the variable is unset inside the subshell.

As a result, _tide_item_character falls through its first branch:

test "$fish_key_bindings" = fish_default_key_bindings && echo -ns $tide_character_icon ||
    switch $fish_bind_mode
        case default
            echo -ns $tide_character_vi_icon_default
        ...

The empty $fish_key_bindings in the subshell fails the equality test, the switch runs, $fish_bind_mode is default, and Tide renders tide_character_vi_icon_default (❮) instead of tide_character_icon (❯) — even though the user is on default (emacs) key bindings.

_tide_item_vi_mode has the same check and is affected analogously.

Fix

Pass fish_key_bindings alongside fish_bind_mode into the subshell's env prefix, in all four fish_prompt variants (1-line/2-line × transient/non-transient). One-line change each.

Reproduction

1. In config.fish (not as a universal variable): set -g fish_key_bindings fish_default_key_bindings
2. Configure Tide with a two-line prompt that includes the character item
3. Open a new shell — the bottom line shows ╰─❮ instead of ╰─❯

Verifying the character function in isolation (_tide_item_character called directly in the interactive shell) prints ❯ correctly, confirming the subshell is where the variable gets lost.

Test plan

• Patch applied locally, exec fish confirms prompt now shows ❯
• Behavior unchanged for users with set -U fish_key_bindings ...
• Behavior unchanged for users in vi mode (subshell now matches parent's key-binding state instead of always defaulting to empty)

[mzilinski]

Closing as duplicate of #619, which makes the same fish_prompt.fish change plus an additional safety check in _tide_item_character.fish. I missed that PR before opening this one. See my comment on #619 for an additional reproduction case (globally-scoped fish_key_bindings from a distro config, independent of fish 4.3).