Windows Alt codes never reach the composer

Noticed while reviewing #535. Pre-existing on every platform build, and #535 changes where it fails rather than whether it does.

## What happens

On a Windows console, holding Alt and typing a numeric sequence on the numpad composes a character — `Alt+0233` gives `é`. crossterm reports it, but as a release:

```rust
// We normally ignore all key release events, but we will make an exception for an Alt key
// release if it carries a u_char value, as this indicates an Alt code.
let is_alt_code = virtual_key_code == VK_MENU && !key_event.key_down && key_event.u_char != 0;
```

and the event it builds takes its kind from `key_down` like any other (`crossterm-0.29.0/src/event/sys/windows/parse.rs:222`), so what arrives downstream is `KeyCode::Char('é')` with `kind: KeyEventKind::Release`. The exception is to crossterm's *own* discarding of releases, not a promise that anyone else will keep it.

Anyone else does not. `tui-textarea`'s `From for Input` discards every release (`tui-textarea-2-0.13.2/src/input/crossterm.rs:44`), so the composed character was dropped there and never typed. #535 adds a release filter of nostui's own, which now drops it one step earlier — the same outcome, a different place.

So: a Windows user cannot type an accented character into the composer with an Alt code.

## What a fix has to decide

The character is not distinguishable from a key release by kind alone, because it *is* reported as one. It can be told apart by shape — a `KeyCode::Char` whose modifiers are `ALT`, arriving as a release — but that is a heuristic, and it has to get past three separate refusals of releases:

1. `terminal_event_to_msg`, which routes a release to `TerminalEventIgnored`;
2. `handle_key_input`, which refuses one before normalising — added in #542, deliberately not trusting the mapping to have dropped it, so editing only the mapping leaves the key silently swallowed one step later;
3. `tui-textarea`'s `From for Input`, which discards releases (`tui-textarea-2-0.13.2/src/input/crossterm.rs:44`) and is not ours to change.

The third is the awkward one: the composer is where the character has to end up, and the crate that owns that buffer drops it on the same grounds. Recognising the Alt code early enough to rewrite it as a press — before any of the three sees a release — is probably the only shape that works without patching upstream.

Worth checking first whether Alt codes are worth supporting at all: modern Windows terminals also accept the ordinary Unicode input methods, and this only affects the numpad route.

## Acceptance

- On a Windows console, `Alt+0233` in the composer types `é`.
- Ordinary key releases are still ignored.