docs: the paused wave has landed; D-60, how much checking a merge gets; Q-9

The plan and the status documents say what is true after the merges
of 2026-10-29: served.md section 0, the 8.0.1 rows and unit Status
lines for S4.4, S5, S6, S7 and P6 (landed, with commits), the 8.0.2
resume paragraph turned into the record of what the merges found,
P6's At-merge bullet (the write-off and dedup interaction, the five
tests its interrupted gate never reached, schema 18), P9a's Done-when 1
verified by the green two-user job, D-58 and D-59 in order.

D-60 (the owner): per merge a compile and the unit's own tests; the
exhaustive gates once per batch, at the end. AGENTS.md's two gate
sentences, HANDOFF.md's merging procedure and the plan carry it, with
the reason: five full gates around five merges took twelve hours and
the one gate at the end found the same five tests.

Q-9 (open, for the owner): P6's `ledger-store` -> `ledger-import`
dependency, with the options and the recommendation; architecture.md
marks the arrow as under review. testing.md records the merge's test
changes under P6. STATUS.md gains "Now (2026-10-29)" with the gate
figures (170 suites, 2,944 tests, 77 minutes), the CI state and the
next steps; HANDOFF.md, roadmap.md, gui.md and the parties doc drop
the paused-branch wording; README counts 129 tools and about 2,950
tests.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HS8WZziDnyxunC23MUxrLp

docs/architecture.md

@@ -31,7 +31,7 @@ the specification in `bookspec/` (which never depends on the engine).
 | `ledger-core` | the semantics engine: money, chart, journal, `Ledger` commands, reports, periods, assets, schedules, parties, A/R and A/P, payroll, projects, settings and conventions, the kernel and its Kani harnesses | nothing |
 | `ledger-vault` | the TIN vault: XChaCha20-Poly1305 records under the book's key | nothing |
 | `ledger-config` | the `wanderbooks.toml` codec (adoption in, `books.export_settings` out) and the receipt policy until P4 moves it into the core | `ledger-core` |
-| `ledger-store` | the source of truth: the hash-chained JSONL journal, its format gate, the SQLite projection (schema 16; a file per schema), the blob store, backups, the access log, `Snapshot` for readers | `ledger-core` |
+| `ledger-store` | the source of truth: the hash-chained JSONL journal, its format gate, the SQLite projection (schema 18; a file per schema), the blob store, backups, the access log, `Snapshot` for readers | `ledger-core`, `ledger-import` (the file reader, P6; Q-9) |
 | `ledger-import` | formats: QuickBooks CSV in; IIF, XLSX, Typst PDFs (statements, the invoice, labels) out | `ledger-core` |
 | `ledger-package` | the shared read-only view over `Store` or `Snapshot` (`PackageBooks`): the CPA package, the 1099 worksheet, the invoice document, Needs attention | `ledger-core`, `ledger-store`, `ledger-config`, `ledger-import`, `ledger-vault` |
 | `ledger-mcp` | the books server: the MCP tools (122), resources, the handbook, scopes, the door and the access log, backups' scheduling | all of the above |
@@ -50,12 +50,14 @@ test `crates/ledger-core/tests/oracle_gnucash.rs` with `oracle/gnucash/`
 (`PackageBooks` is the shared view; extraction is in-process in
 `ledger-import`, P6).
 
-Pending (the P6 branch, 2026-10-27, unmerged): P6 made `ledger-store`
-depend on `ledger-import` so the writer can extract a file's text at
-attach time and on the backfill command. That keeps the direction inward
-but pulls Typst, the fonts and hayro into the store's dependency closure;
-whether it stands, or extraction moves to the server before the store
-call, is decided at P6's review.
+Under review (Q-9, asked 2026-10-29 when P6 landed): P6 made
+`ledger-store` depend on `ledger-import` so the writer can extract a
+file's text at attach time and on the backfill command. That keeps the
+direction inward (`ledger-import` depends on the core alone and must
+never depend on the store) but pulls Typst, the fonts and hayro into the
+store's dependency closure. The plan's recommendation is a small library
+crate holding the reader that both depend on; until the owner decides,
+the arrow stands as drawn above.
 
 `ledger-core` itself (`crates/ledger-core/src/`): `money`, `account`,
 `journal`, `ledger` (the command surface and replay), `kernel` (every
@@ -128,7 +130,7 @@ and version; `Store::verify` checks the text blob's hash and never
 re-derives it. The server's filing scan (`tin_files`) and the viewer's PDF
 rasterizer read through the same module, so a PDF's text is read one way.
 Annotations and settlements are ledger state (`ledger_core::evidence`,
-`Ledger::differs_from`), projected into schema 16's `annotations` table;
+`Ledger::differs_from`), projected into schema 18's `annotations` table;
 extractions have a table of their own. The viewer's Documents page groups
 by category and filters by subject; Needs attention reads both through
 `PackageBooks`.
@@ -165,7 +167,7 @@ engine keeps them beside the ledger (`ledger_core::settings::Settings`,
 `ledger_core::conventions::Conventions`, fields of `Ledger`), so the store,
 its replay and the viewer's `Snapshot` share one reading; `Ledger::
 differs_from` and `verify` compare them, and the projection has a table
-for each (schema 16 on 2026-10-28; a file per schema). `ledger-config` is the codec between them and a
+for each (schema 18 on 2026-10-29; a file per schema). `ledger-config` is the codec between them and a
 `wanderbooks.toml` (`codec::import`, `codec::export`): adoption (`wanderbooks
 books adopt`) moves an older books dir's file in through it, once, and
 `books.export_settings` writes the books' settings out as one. The books