S12 - Async feedback for scheduling

specs/refined/S16_store-state-in-persistent-storage

@@ -69,6 +69,34 @@ JSON remains the import/export format, rather than the primary storage model.
   interrupted, rather than remain indefinitely marked as running. They do not
   resume automatically. Previously saved results remain available.
 
+## Persistent scheduling status (transferred from S12)
+
+The maintainer explicitly moved durable scheduling status and backend-restart
+recovery from S12 to S16 when completing S12. S12 supplies background execution,
+status snapshots, SSE and notifications within the lifetime of the backend.
+
+- Persist the latest calculation per show in PostgreSQL, including its run
+  identifier, school/show identity, start and finish timestamps, state, latest
+  phase, whether a valid solution was found, outcome explanation and final
+  attendance/spread/variety summary when available. A run history is not required.
+- Persist acceptance of a run before acknowledging its start. After restart or
+  crash, an accepted calculation must remain identifiable even if it never
+  produced a result.
+- Commit successful assignment replacement and its completed run status
+  atomically. Publish success through the status API and SSE only after the
+  transaction commits. A failed commit must not leave a successful status with
+  missing assignments, or replaced assignments with an outdated running status.
+- On startup, mark calculations left Running by the previous backend instance
+  as Interrupted before serving their recovered status. Explain that no new
+  result was applied, retain previously saved assignments and allow a new run.
+  Do not resume calculations automatically or retain their old run-slot guards.
+- Recover the latest status and outcome through S12's existing status endpoint
+  and initial/reconnection SSE snapshots. Preserve stable run identifiers so
+  reconnecting clients can deduplicate notifications; reopening the application
+  must not replay old completion snackbars.
+- Verify recovery after both graceful restart and abrupt process termination,
+  including a calculation running at termination and a completed saved result.
+
 ## Database failures and schema changes
 
 - Refuse mutations while the database is unavailable and provide a clear failure
@@ -103,8 +131,14 @@ for now. S16 does not promise recovery after loss of the database or its volume.
       another: the stale edit receives a clear conflict response, and the user
       can reload and retry.
 - [ ] Scheduling results based on outdated input revisions are rejected.
-- [ ] Interrupted calculations are recognizably interrupted after restart;
-      previously saved results remain available.
+- [ ] The latest accepted scheduling run, its stable identifier, timestamps,
+      progress, outcome and objective summary survive normal restart and crash
+      and are returned through the status API and SSE snapshots.
+- [ ] Successful assignment replacement and completed run status commit
+      atomically; success is published only after durable commit.
+- [ ] Calculations left Running become Interrupted before recovered status is
+      served; previous assignments remain, no automatic resumption occurs and a
+      new run can start. Reopening does not replay old completion snackbars.
 - [ ] Database unavailability prevents successful mutation acknowledgements;
       startup connection and migration failures are clearly reported.
 - [ ] An empty database can be initialized through Flyway and populated through