Read-only mode still offers actions that cannot work

Raised during #520 review round 12. #520 makes these fail honestly and immediately; this issue is about not offering them in the first place.

## What happens now

With an `npub` configuration there is no key to sign with, so no publish can succeed. After #520:

- `n` opens the composer, `Ctrl+P` reports `[ERR: Note] read-only mode (…)` and keeps the draft.
- `f` and `t` report `[ERR: Reaction] read-only mode (…)` / `[ERR: Repost] …` on every press.
- The NIP-38 status simply does not run.

That is a strict improvement on the previous behaviour — the command used to be queued, fail in the worker, and (for a note) take the draft with it. But the user can still press the key, and gets a repeatable error for something that could never have worked.

## The correct-by-construction version

Gate the actions rather than the sends: in read-only mode, the compose / react / repost keybindings do not resolve to those actions at all, and the help or status makes it clear why. Then there is no failure to report, and no error line to repeat.

That is a keybinding and presentation change rather than a publish-path one, which is why #520 does not do it — it would mean deciding how the mode is surfaced (a marker in the status bar? a note in the help?) rather than just refusing a send.

## Worth deciding together

- Whether read-only is communicated anywhere today. A user who configured an `npub` may not realise the app is read-only until they try to post.
- Whether the composer should open at all, or open in a state that says why it cannot submit.

## Acceptance

- A read-only configuration cannot reach an action whose only outcome is a "read-only mode" error.
- The user can tell the app is read-only without having to try to publish.