Save button announces success on failed and no-op saves

[BootBlock]

The Save button announces success unconditionally, including when the save failed or when there was nothing to save.

src/ui/shell/TransportBar.tsx:

onClick={() => {
  void useProjectStore
    .getState()
    .saveNow()
    .then(() => announce('Project saved'));
}}

AutosaveQueue.flushNow() is documented and implemented to never reject: on failure it catches, re-queues the batch, calls onError and returns false; flushNow re-arms and returns. So:

• A failed write resolves the promise → "Project saved" is announced.
• With a null queue (see the session-boot issue) saveNow() is await queue?.flushNow() → resolves instantly → "Project saved" is announced when there is no project at all.

There is no .catch on the chain, and the boolean flushNow returns is discarded.

§4.4 requires saveNow() to be surfaced in the UI. It is surfaced — but it reports success it has not verified, which is worse than not reporting at all, because the user stops checking.

Suggested fix

Have saveNow() propagate the outcome (return the flushNow boolean, or reject) and announce accordingly — "Project saved", "Save failed — retrying", or "Nothing to save". The autosave onError toast already knows a failure happened; the explicit Save path should not contradict it.

[BootBlock]

Fixed in 7de61e4 (merged to main).

AutosaveQueue.flushNow() now resolves with a SaveOutcome — 'saved' | 'failed' | 'idle' — rather than void. It still never rejects (that is what keeps auto-flushes from surfacing unhandled rejections), but the verdict is now carried in the resolution value. ProjectService.saveNow() propagates it and maps a null queue to 'idle', and the Save button announces per outcome.

A save coalesced onto an in-flight flush inherits that flush's outcome instead of reporting 'idle' — the in-flight write is what saved the work.

One deviation from the suggested wording: the failure announcement is "Save failed — your changes are not saved" rather than "retrying", because an UnflushableKeyError batch is deliberately dropped rather than retried, so a retry promise would be false for that case.

Labels: added autosave and accessibility (the defect was a false live-region announcement); dropped storage — nothing in the storage layer changed.