merge: P4b S4.4, the create tools preview and confirm, the party contact block (branch S4.4, 002fb9f8)

The first of the five paused branches (plan 8.0.2, "Resuming the paused
wave"). books.create_invoice and books.create_bill preview without
confirmed and post with it (A-1), the issued PDF filed in the same
store call, the party's full contact block (D-55) on books.update_party
and the invoice's bill-to. The only conflict was docs/parity.md, where
the 2026-10-28 review had written the S1-S4.3 notes on the A/R and A/P
rows and S4.4 its own: both are kept.

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

plan/served.md

@@ -1330,6 +1330,16 @@ Each unit follows the 8.0.4 template. "A-n" is an owner answer numbered in 8.3.1
    - Item 13's 8.0.6 item 3 (R-A step 4): the over-the-wire call for a *document* carrying the new fields cannot exist before S4.4's tool arguments do, so `books_p2_served_cut_over_whole` keeps S4.2's `invoicing.default_terms` entry, which refuses before consent and is taken after; the store-level before/after is `documents_v2_waits_for_the_upgrade`. S4.4 adds the document call to the same list.
    - `issued_pdf_is_filed_with_the_invoice_or_nothing_is` proves every *refusal* leaves the journal unchanged; `create_invoice_issued` has no transaction over journal appends, so a storage failure between the invoice's lines and the attachment's is not rolled back. The PDF's bytes are stored before the first line, so that window is an I/O failure alone.
    - `preview_invoice` takes a number only in books that have declared `documents_v2`, so books that haven't keep the legacy "Invoice {id}" shape and can still file an issued copy before the upgrade (8.3.14 item 5).
+   S4.4 (2026-10-27), departures only:
+   - 8.0.6 item 3: `books_p2_served_cut_over_whole`'s refused list now holds both document writes (`books.create_invoice` with `terms` and a project line, `books.create_bill` with `vendor_ref`, a line account, a project and an existing attachment), and the same calls are made after the consent; S4.3's store-level test stays.
+   - The preview needed the document the issue would store before the invoice exists, and the account codes of a posting whose accounts the live chart doesn't have yet, so `InvoicePreview`/`BillPreview` gained `lines` (`PreviewPosting`: code, name, side, amount, project, resolved by the probe) and `InvoicePreview` gained `invoice` (the probe's document). `posting` stays: S4.3's test reads it.
+   - The DRAFT and issued pages are built by `ledger_package::draft_invoice_document` and `issued_invoice_document` (new), both taking the probed invoice and rendering through the page builder `invoice_document` already uses, so S4.5 enriches the renderer once. The server renders the issued copy before the store call and `create_invoice_issued` files exactly those bytes; the confirm passes the preview's number as the issue's number, so the filed page prints the number the preview showed (a number another session took in between is refused as a duplicate, B-40).
+   - Item 15's `vendor_ref`, a line's `account` and the file are required only in books that have declared `documents_v2`, reading its last sentence ("on books without the feature, lines without `account` post to `6999` as before and the file is optional") as the general case: requiring a `documents_v2` field always would refuse every bill on the owner's books before the go-ahead, against 8.0.4's "everything else in the unit works at once".
+   - The confirm is the preview's own rehearsal plus the write: `preview_invoice`/`preview_bill` run first on every call, so a preview refuses exactly what the confirm would; the tool's own checks (the vendor's number, the line accounts, the file) come after the lines resolve, so an unknown project still names itself.
+   - `books.update_party`'s handler stays in `crates/ledger-mcp/src/tools/parties.rs`, its own group file (U0a's rule); only the document tools' handlers are in `tools/documents.rs`. It asks `documents_v2` before its first line when any of the email, terms or contact fields is given, never between them.
+   - D-55: `PartySnapshot::from_party` is the one place the billing-else-general rule lives (an invoice's bill-to `address`/`email` are the billing ones when set); the snapshot carries the whole block, and `PartyOut` gained the email, terms and contact fields so `books.party` shows what `books.update_party` sets.
+   - Item 17's `documents_v2_refused_until_consent` is in `crates/ledger-cli/tests/format_upgrade.rs`; the wire tests are in the new `crates/ledger-cli/tests/documents.rs`, and D-55's round-trip and at-issue tests in `crates/ledger-store/tests/parties.rs`.
+   - Existing callers of `books.create_invoice` and `books.create_bill` gained `confirmed: true` (and a bill its vendor's number, line accounts and file): the contract A-1 changes. Two tests that named `books.create_invoice` as a tool a write token cannot see now name `books.receive_payment`, since a write token may preview an invoice.
 
 #### P4b S5: sent tracking (`invoice.sent`)