Revisit the draft save no-retry decision now that a failed save is a partial commit

Before per-book partitioning, the draft was one record: a rejected write was a no-op, leaving the previous draft intact.

Now the analysis spans several records, written before the envelope. A save that fails partway persists a partial state — some books from the new save, the rest from the old one — which stands until the next keystroke triggers another auto-save, and permanently if the user stops editing at that moment.

The next save does repair it: what reached storage is tallied as it lands, so the following save rewrites only the books still missing it. The gap is only that nothing forces a next save to happen.

That makes the documented no-retry decision more expensive than when it was made, which is worth revisiting on its own rather than inside the PR that changed the cost. Options include retrying a failed draft save, or surfacing the failure so the user knows the draft on disk is mixed.

Raised by @imnasnainaec (drafted by Devin) reviewing #316, and deferred from it as out of scope.

Start by reviewing the changes in #316 and the documented no-retry decision, focusing on the per-book records written before the envelope. Trace how a failed draft save leaves mixed state and how the next save repairs it. Done means the project has a decided and implemented response to failed saves, such as retrying or clearly surfacing the mixed draft state.