docs(website): settle boot/shutdown dispatch and what a boot writes down

Records phase 2 PR 5 of the module system: the lifecycle hooks a module
registers, how they are dispatched, and what a boot does to installed_modules.

MODULE_API.md 2.5 gains the reconcile's four steps in order, the rules that fall
out of them (the operator's `disabled` wins over any outcome; a bookkeeping
failure is not a boot failure; a module with no onBoot still reaches `started`;
a module whose onBoot threw gets no onShutdown), and why onBoot has no timeout
while onShutdown has a five-second budget -- shutdown races the process being
killed and boot does not.

4.4 gains the failure_stage table: every failure is recorded against the 4.3
step that produced it, so the admin panel can say where a module broke and not
only what the message was.

MODULE_SYSTEM.md 2.4 records the new rule for a row whose directory is gone, and
2.7 the PR 5 progress entry with its four decisions. BACKEND_DESIGN.md's
installed_modules section gains the write path now that one exists.

Co-Authored-By: Claude <noreply@anthropic.com>

website/BACKEND_DESIGN.md

@@ -690,6 +690,14 @@ who fixes the cause needs no admin-panel visit), a running module can never disp
 and `disabled` — the one operator *decision* rather than outcome — survives untouched. A re-install or
 upgrade refreshes the metadata and leaves `state` alone.
 
+The write happens in one place, `src/modules/lifecycle.js`, on the boot path after `ensureSchema()`
+and before the listener binds: it resets the last boot's outcomes, writes a row for every module found
+on the volume (with NULL provenance for a hand-placed directory), marks any row whose directory is
+**gone** `startup_failed`, and then runs each surviving module's `onBoot` and records what happened. A
+`disabled` row is guarded, not booted, and never has its failure re-recorded — an outcome must not
+overwrite the operator's decision. Every one of those writes is individually caught: a row that will
+not update is worse reporting, never a failed boot.
+
 Design of record: [`MODULE_SYSTEM.md`](MODULE_SYSTEM.md) §2.4; the loader's obligations are
 [`MODULE_API.md`](MODULE_API.md) Part 4.