nostui does not notice when the Nostr worker dies

Split out of #511 during its re-scope. The work described here was written and reviewed inside that PR and then cut from it, because it is connection-loss handling rather than publish confirmation. The reasoning is preserved so it does not have to be rediscovered.

## The gap

The subscription worker is a detached task. When it goes away — its stream ends, or it panics — nothing tells the application:

- `AppState::command_sender` stays `Some`, and `model::nostr` goes on reporting `connected`, so every subsequent dispatch is handed to a channel with no reader. Each one rediscovers the dead worker independently.
- Commands sent in that state are dropped. For a publish that is now visible (it settles as a failure), but a `Subscribe` or `Unsubscribe` disappears silently — which is the other half of #518.
- Anything the application is waiting on the worker to answer waits forever.

## What was built and cut

Two pieces, both reviewed and green, removed from #511 as out of scope:

**Record the loss in the dispatcher.** `dispatch_nostr` returns whether the command reached the worker, and on failure applies `NostrMessage::ConnectionLost` and clears `command_sender`. Doing it in the dispatcher rather than at each call site is what stops it drifting — an earlier revision had the recovery in the publish path only, and subscribe/unsubscribe silently lacked it.

`ConnectionLost` is deliberately narrower than the existing `ConnectionClosed`: the latter also clears `feed_subscriptions`, which is correct when nostui is closing the connection on purpose and wrong when the worker vanished, because the tabs are still open and their subscription ids are what a replacement worker needs in order to unsubscribe.

**Fail whatever the dead worker still owed.** A publish queued when the worker exits normally is reported by the worker's own exit drain. One left by an abnormal exit is not, so it shows "Sending" until something clears it. `on_connection_ready` failing the outstanding entries covers that, and has to run *after* the "loading..." line it would otherwise be overwritten by.

## Acceptance

- After the worker dies, the next dispatch reports the connection as lost rather than rediscovering it, and the gateway stops claiming to be connected.
- A publish left pending by an abnormal worker exit is settled rather than showing "Sending" indefinitely.
- Recovery does not discard the subscription ids that a replacement worker needs (i.e. it is not `ConnectionClosed`).

Start at dispatch_nostr, AppState::command_sender, and model::nostr, then trace how NostrMessage::ConnectionLost and ConnectionClosed are handled. Inspect on_connection_ready and the worker exit paths, using the acceptance criteria to verify that lost connections are reported, pending publishes settle, and subscription ids remain available for recovery.

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