The which-key popup and the pending keystrokes indicator listed every
binding that starts with the pending keys, including ones disabled with
`null` or `zed::Unbind`:

```json
"cmd-k p": "editor::CopyPath",
"cmd-k p": null               // user keymap: CopyPath still showed as `p` after `cmd-k`
```

Key dispatch doesn't change. `Keymap::possible_next_bindings_for_input`
now checks what dispatch would run for each binding's full keystrokes,
and hides the binding if it isn't one of them. That applies the same
rules dispatch uses: a `null` in the `Workspace` context doesn't hide an
`Editor` binding, and a `null` in a base keymap doesn't hide your own
user bindings.

The check calls `resolve_bindings_for_input`. That's the existing body
of `bindings_for_input`, moved out so it can run over a list of bindings
the caller passes in. The popup uses the same code as dispatch, so the
two can't drift apart. It passes only the bindings that extend the typed
keys, not the whole keymap, so each check stays cheap.

Release Notes:

- Fixed the which-key popup and pending keystrokes indicator showing
keybindings that were disabled with `null` or `zed::Unbind`.
- [GPUI] Fixed `possible_bindings_for_input` returning bindings disabled
with `null` or `zed::Unbind`.