fix(which-key): show delayed popup before blocking input

[AndreaCovelli]

Summary

• wait for the delayed popup before entering the blocking key read
• keep polling for pending input so fast follow-up keys still skip the popup path
• document the new schedule filter field used by the forced refresh

Reproduction

1. Open one file in a fresh Neovim instance.
2. Create a vertical split and open a second file there.
3. Press <leader> in the second split.
4. The popup can stall until timeoutlen expires, even though the same mapping is immediate in the first window.

In my repro this showed up consistently when opening one buffer first and then creating the second split, but not when starting Neovim directly with -O.

Root cause

which-key.state.start() schedules View.update() and then immediately blocks in getcharstr(). In the affected split-window flow the timer-backed popup refresh does not get a chance to render before that blocking read.

This change waits until the popup delay elapses, while polling getcharstr(1) so a pending next key is not consumed. If no follow-up key arrives, it forces an immediate View.update({ schedule = false }) before entering the blocking read.

Validation

• reproduced the stall locally in a split-window flow
• nvim --headless -u NONE --cmd 'set rtp+=/tmp/which-key.nvim' '+lua require("which-key.state")' '+qa'
• git diff --check

Testing note

Full test suite and stylua pass locally (Neovim v0.12.2, stylua 2.5.2):

• stylua --check lua/ tests/ all files formatted correctly
• all test cases pass (0 failures, 0 notes) across buf_spec.lua, layout_spec.lua, mappings_spec.lua, util_spec.lua