Holding a key publishes a reaction, or a repost, once per repeat

Raised on #542 and, as filed there, understated: this is not latent and #542 is not what makes it reachable. Corrected here.

## What happens

Hold a key that is bound to something, and the binding fires once per repeat. That is ordinary terminal auto-repeat: a held key sends its bytes again and again, crossterm parses each as a plain `Press`, and each one resolves and acts. No protocol and no special terminal needed — it happens on every build today.

| held | shipped binding | per repeat |
| --- | --- | --- |
| `f` | `React` | one NIP-25 reaction published to the same note |
| `t` | `Repost` | one repost published |
| `Ctrl+W` | `CloseCurrentTab` | one tab closed, then the next |
| `n` / `r` | `NewTextNote` / `ReplyTextNote` | the composer opens, and the rest of the held key types into it |

What #542 changed is narrower than the first version of this issue claimed: it makes the *kitty protocol's* `Repeat` events resolve too, alongside the plain presses that always did. Since nostui never asks for that protocol, that half is latent. The plain-press half is not, and predates it.

## Why it went unnoticed

The two most obvious ones are self-limiting. `Ctrl+W` runs out of tabs; `n` opens a composer that swallows the rest of the held key. The publishing pair is the one that keeps going: `f` and `t` have nothing to stop them, and each repeat is a real event on the relays that cannot be recalled. A user who leans on `f` sends a burst of identical reactions and sees one status line.

## What a fix has to decide

- **Which actions may repeat.** Scrolling and tab switching obviously. Publishing, closing, and opening the composer obviously not. `Quit` is arguable — it is idempotent in effect, and the first one ends the process anyway.
- **Where the decision lives.** Next to the action, as a property of `KeyAction`, rather than as a list in the key path — otherwise the next action added inherits whichever default the list happened to have.
- **What "repeat" even means here.** The kind cannot answer it: an auto-repeat arrives as a run of ordinary presses, indistinguishable from someone pressing the key quickly on purpose. So this is a debounce or a rate limit on the action, not a filter on the event — and #542's normalisation is beside the point rather than in the way, except for the protocol's repeats, which it does flatten.

## Acceptance

- Holding `f` on a note sends one reaction, not one per repeat.
- Holding a key bound to scrolling keeps scrolling.
- Adding a new `KeyAction` requires saying which of the two it is.

Start by tracing KeyAction handling and the key path, then compare ordinary presses with the kitty Repeat behavior described in #542. Verify the chosen action policy against the acceptance cases: publishing once, scrolling repeatedly, and requiring each new KeyAction to declare its repeat behavior.

由索引模型根据 Issue 内容生成。