Persist outputs to a store

[SimonHeybrock]

Implements persisting, the third part of the design in #50: nothing is written unless persisted, and the store keeps what is. Stacked on #51, which is stacked on #50.

What changes

• The backend takes a store (local(store=...), Backend(..., store=...)). ess.dispatch.testing.FakeStore holds values in memory; without a store, persisting is refused.
• client.submit(..., persist=True | names) and client.freeze(acc, persist=...) hand the records to the store: the client does not keep them, the record finishes once the outputs named are written, and a failed write fails the record with the write's reason.
• client.persist(records, *outputs) adds the store next to the client's hold. A failed write fails only that persist request; the client may ask again.
• Every client of the proposal reads and references persisted outputs. A request or a read that may read an output only because it is persisted waits for the write, and fails if the write fails.
• History logs persist requests and writes. A record of an accumulator's state is logged as the accumulator and its number of pushes, and its rows are listed when it is read, so history grows by a constant amount per read.
• A restart cancels pending work that no persist request needs, runs persisted work whose inputs are datasets, written, or produced by work that runs, and fails the rest; records of states fail. A write of a completed record that had not ended has failed.
• Closing a backend waits for pending writes. The trigger loop persists what a rule names, every output by default.
• The story tests D1 to D3, D6, and D7 now persist as their text says; F2 uses the upgraded client. The story fixtures have a fake store, and upgrade takes over the history and the store after ending the old clients.

Why

The service must not keep values for unattended work, and must not write what nobody asked for (ADR 0005). Logging records of states by count gives the restart rule the marker it needs and keeps history linear in the number of pushes (ADR 0004).

ADR 0005 contradicted itself on a record persisted at submission whose write had not ended at a restart. The log cannot tell a write in progress from a workflow still running, so such a record follows the ordered restart rule and runs again; the docs now say so.

Test plan

• pytest -n auto in packages/essdispatch (203 passed, 6 xfailed) and packages/essspec (99 passed), several runs
• New tests/persist_test.py: persisting at submission, client.persist, failed writes, readers that wait for a write, freezing with persist=, closing, and the restart rules

🤖 Generated with Claude Code