fix(relay): validate keys in the grammar herdr actually accepts

SAFE_KEYS was a tmux-flavoured literal set, and four things were wrong with it.

`BSpace` was in it and could never have worked: herdr answers `invalid_key:
unsupported key BSpace` to every spelling. It has been an entry in an allowlist
that guarantees the relay forwards a key the CLI then refuses.

No chord was in it, so the Ctrl presets the web app composes at runtime
(ctrl+/shift+ any key) were rejected wholesale before reaching herdr -- which
does accept them. herdr's grammar is `+`-joined and matches special names
case-insensitively, so `ctrl+c`, `alt+Up`, `shift+tab` and `esc` are all valid
and none of them could be sent. The mac app's Ctrl+c only ever worked because
it invokes the local CLI instead of the relay.

`keys` was never checked for being a list, and `all()` iterates a string.
`keys: "yn"` therefore passed -- both characters are in the set -- and went out
as two separate keys, so a client that sent a string instead of an array got
its text typed into the pane rather than an error.

And `keys: []` passed vacuously, issuing `pane send-keys <pane>` with no key
argument at all, while `keys: null` raised TypeError out of a handler whose only
except catches ConnectionClosed -- dropping the client's connection.

key_is_allowed() replaces the set membership test with the two shapes herdr
takes, all live-verified against herdr 0.8.0 (protocol 19) on a throwaway
session. `C-c` stays because it is the one tmux spelling herdr still aliases to
interrupt -- `C-u`, `M-x` and `BTab` do not. A repeated modifier
(`ctrl+ctrl+c`) is refused here regardless of what herdr does with it: it only
arrives from a client bug, and a live terminal is not where to find that out.

SAFE_KEYS stays a self-contained literal expression because
tests/test_telegram.py evaluates it straight out of the AST.