The NIP-38 status line reports what nostui attempted, not what a relay accepted

Split out of #520, which confirms publishes against the relay's answer for everything the user does — notes, reactions, reposts — and deliberately leaves the NIP-38 music status alone.

## Why it was left out

Routing it through the same path made it report relay rejections, and many relays refuse kind 30315. A user with `nip38.enabled` would then get `[ERR: Music] no relay accepted the event: …` painted over the status bar **on every track change**, for something they never asked for and cannot act on. Those rejections were invisible before, because the `Ok(output)` was discarded.

Confirmation exists so the user is not told their *own action* succeeded when it did not. A track change is not their action, so #520's scope stops at user-initiated publishes and the music line keeps its old meaning: what nostui attempted.

## What is still not true

`[Music] Song - Artist` appears whether or not any relay took the event. That is the same shape of claim #511 was about, weaker only because nobody is relying on it.

## What a fix would need to decide

- **Where it belongs.** An error over the user's status bar is the wrong home for it; the noise is the reason it is out of scope now. Somewhere it can fail quietly — the log, or an indicator that does not compete for the status line — is the question.
- **Whether it should report at all.** Failing to publish a now-playing status is arguably not worth telling anyone. If so, the honest fix is for the line to stop implying success: "Music: X" as a statement about what is playing, not about what was published.
- This overlaps #516: whatever arbitration lands there decides whether a background publish may take the status line at all, at any point in its lifecycle.

## Acceptance

- The line does not assert a publish that did not happen.
- A relay refusing kind 30315 does not put an error in front of the user on every track change.