sqlite: run_schedules' failed-renewal arm classifies as Database, never LeadershipLost (review 004 item 9) — a lost lease (Ok(false)) keeps the respawn arm unchanged; a failed renewal (closed store / storage failure) propagates its opaque classification, so respawning misdirects at a dead store no more; dated (2026-10-11) ADR-017 §2 class-1 annotation of the loss-vs-failure arm set in ADR-009 §1, core-contract §Errors, queues.md, engine-sqlite.md, core+sqlite doc comments; two tests pin both arms; pg twin recorded for follow-up; task -> completed

docs/architecture/decisions/009-scheduler-collapse.md

@@ -97,6 +97,19 @@ store.run_schedules(stop) -> Result<()>        // runs until `stop`
   on it. (One taxonomy note: `LeadershipLost` is a *return-shape*
   variant of the runner, pinned by the same act-differently rule as
   ADR-008 §5 — the caller acts on it by respawning.)
+  *(Annotated 2026-10-11 — review 004 item 9; amend-in-place per
+  ADR-017 §2 class 1, no publish tag exists.)* The loss arm is the
+  refused renewal (`renew` → `Ok(false)`): the lease expired and was
+  re-acquired elsewhere. A *failed* renewal is not a loss and never
+  returns `LeadershipLost` — the lock semantics were never reached:
+  a closed store (respawning a leader against a dead store is
+  misdirected; the engine-wide closed-store posture applies) and
+  storage failure both surface the opaque `Database` fallback with
+  the engine detail preserved via the source chain. Engines whose
+  renew is infallible (`Ok(bool)` only) have no failure arm to
+  classify; engines whose renew can fail must propagate the `Err`
+  unchanged (the SQLite engine's pre-annotation flattening —
+  `unwrap_or(false)` — was the finding).
 - Schedules do not fire until a consumer runs `run_schedules` — the
   opt-in is explicit, the no-ambient-timers posture holds,
   [ADR-002](002-feature-scope.md)'s scheduler evidence is served, and