feat(desktop): clarify message delivery states and failure recovery

### Problem

Desktop local-message delivery states do not clearly answer whether a message was delivered, what is happening next, or how the user can recover.

In the reported Stop → send → send again flow, user messages appeared as ordinary right-aligned bubbles while small metadata distinguished a retained failed copy from a Host-accepted message. Recovery offered “Remove local copy”, which describes storage rather than the user's action. A model failure banner between repeated messages also made it difficult to identify which attempt failed and whether the latest attempt was progressing.

The confirmed delivery blockage is tracked separately in #5007 and fixed by #5008. This issue concerns presentation and recovery after that scheduling fix.

An additional ambiguity: `Host accepted` covers `turn_started`, `steering`, and `followup`. These mean a new Turn, input to the current Turn, and queued input respectively; acceptance alone does not promise a separate reply. Accepted local rows remain transient until the canonical transcript contains their message ID. Users should not need to infer these distinctions from a retained bubble or its position.

### Desired outcome

- Clearly distinguish sending, waiting to send, definite failure, unknown delivery outcome, accepted/queued, and active processing using user-facing language. Explain automatic retry/checking only when the implementation actually performs it.
- Make failed-message state visible and offer an edit-and-resend path preserving text and attachments. Only offer direct retry when delivery semantics make it safe; uncertain outcomes must reconcile the original identity first.
- Use a clear removal label with predictable consequences. Removing a local failed message must not imply cancelling an execution already accepted by the Host.
- Associate delivery errors with their message and model/execution errors with their Turn, so later recovery does not look like a continuing global error.
- Explain the stop/send transition, including whether new input is waiting, joining the current Turn, or queued for another Turn. Do not leave “Host accepted” as the only progress explanation.
- Keep local and canonical user messages aligned to the same conversation reading column. The screenshots show local rows near the far window edge; verify geometry across pending, accepted, and canonical states before treating this as a confirmed layout defect.
- When the canonical transcript takes over, preserve one visible copy and a stable visual position. User-message right alignment is fine; shifting to a different horizontal column based on delivery state is not.

Include before/after visual evidence and exercise definite failure, unknown outcome, queued input, and canonical handoff. This issue does not establish the original Stop-to-first-refusal trigger.

### Alternatives or workarounds

Currently users infer progress from small delivery labels and may delete/re-enter or repeatedly send the same text. #5008 removes the need to delete a failed copy to unblock later sends, but does not improve wording, recovery affordances, or layout continuity.

Prepared with OpenAI Codex on behalf of @me2seeks.