Status bar arbitration should be correct by construction, not by accumulated conditions

Split out of #513. Not a bug report — the conditions there are correct as far as they go, and every case below is handled today. The problem is *how* they are handled, and that shape is what kept generating findings.

## What happened

#513 gave publishes a pending state (`[Sending] …`) that settles when a relay answers. That turned the status bar from something written synchronously at one point into something written twice, seconds apart, by events the user did not necessarily cause. Four consecutive review rounds then found gaps — each one real, each one fixed by adding a condition:

| Round | Gap | Condition added |
| --- | --- | --- |
| 4 | A user's confirmation was swallowed by a newer pending line | Announce unconditionally when the origin is the user |
| 6 | A quiet automatic failure left `[Sending]` standing forever | Retire the line if this publish still owns it |
| 7 | Scrolling clears the bar, so `Music` stopped appearing | Also announce onto an empty bar |
| 8 | Two publishes with identical text settled each other | Identify by `PublishId`, not by rendered text |
| 10 | A stale automatic success named a superseded track | Stay quiet while a newer automatic publish is pending |
| 10 | A user's success wiped another publish's error | Do not announce over an unacknowledged failure |

The decision now reads on four axes — origin (user / automatic), what the bar holds (this publish's pending line / an unread failure / neither), whether the bar is empty, and whether a newer automatic publish is outstanding. Each condition is defensible in isolation and none of them is wrong. But every round found the next uncovered combination, which is the signature of a model that enumerates cases rather than one that makes the bad cases unrepresentable.

## What the model should be

There is an ordering hiding in all six rows above, and once it is named most of the conditions disappear:

```
failure > user confirmation > automatic confirmation > pending line > empty
```

Every rule added in #513 is an instance of "do not write something of lower standing over something of higher standing, unless the thing already there is your own."

So the shape worth having is a status bar that takes a *priority* along with the message and enforces the comparison itself, rather than callers deciding case by case whether it is their turn. Something like:

- `StatusBar` stores the current message together with its priority and the id of whatever owns it.
- A write lands if its priority is at least the current one's, or if it comes from the current owner (a publish is always allowed to update or retire its own line).
- Retiring a line is the owner clearing it, which no longer needs a separate ownership check at every call site.

Then "a stale automatic success must not overwrite a newer one" stops being a rule to remember: the newer publish owns the line, the older one is not its owner and has no higher priority, so it cannot land. Same for the failure case, and the empty-bar case falls out because nothing has priority over nothing.

## Why not in #513

Restructuring how every status message is written is a change to code far outside publish confirmation — tab loading, errors, startup — and doing it in the tenth round of a PR about something else would be the third time in that PR that a broad change was made in response to a narrow finding. #513's conditions are tested and correct; this is about not having to keep adding them.

## Acceptance

- Callers state what they are writing and how important it is; none of them inspects what is currently displayed.
- The six rows in the table above hold without a condition per row, and each keeps its regression test from #513.
- Adding a seventh kind of status message requires choosing its priority and nothing else.