bernstein receipt has no reference page, so its contract lives in one FEATURE_MATRIX cell

[chernistry]

bernstein receipt has no reference page. Its behaviour is documented in one cell of FEATURE_MATRIX.md, and that cell is now a 90-word paragraph carrying four separate claims — because a matrix row is the only place the contract is written down, every clarification lands there.

The row itself admits the gap: it points at no page.

What the row is being asked to hold

After #4050 the receipt verifier reports two independent facts — whether the manifest digest was checked, and whether chain continuity was checked — which are computed from different inputs and can disagree. The distinction needs a paragraph and an example of each combination. A table cell cannot carry that and stay checkable, which is the FEATURE_MATRIX contract.

Scope

Add docs/reference/receipt.md covering the bernstein receipt verify surface:

• Every flag, from --help, reconciled against the actual parser rather than the current prose.
• The two verification facts, what each is computed from, and what it means when they disagree.
• The verdict shapes: verified, refused, and the malformed-input verdicts — one worked example of each, with the exact output.
• What a receipt does not attest, which is the question the current row invites and does not answer.

Then shrink the FEATURE_MATRIX.md row to one sentence plus a link, and add the page to mkdocs.yml nav.

Proof

• A test asserts every subcommand and flag named on the page exists in the parser, so the page cannot drift into describing a surface that moved. tests/unit/ — the docs-drift gate is the model to follow, not to duplicate.
• uv run python scripts/check_docs_drift.py clean.
• uv run mkdocs build --strict clean (nav entry resolves).

Out of scope

• No behaviour change to bernstein receipt. If the page cannot describe the current behaviour honestly, say so in the thread rather than adjusting the code to match the page.
• The other FEATURE_MATRIX rows. One row, one page.

The decision left to whoever takes this

Whether the page documents the verdict shapes as a table or as worked examples. Both are defensible: the table is checkable at a glance, the examples show the output a reader will actually see. Pick one and say why in the PR — do not do both.

Agent brief

Repo: sipyourdrink-ltd/bernstein. Read docs/playbooks/docs-drift.md and
FEATURE_MATRIX.md's `bernstein receipt` row first, then
src/bernstein/cli/commands/receipt_cmd.py and
src/bernstein/core/security/result_receipt_bundle.py for the actual surface.

Write docs/reference/receipt.md documenting `bernstein receipt verify`: every
flag reconciled against the parser, the two independent verification facts
(manifest digest, chain continuity) and what a disagreement means, one worked
example per verdict shape, and what the receipt does not attest.

Shrink the FEATURE_MATRIX row to one sentence plus a link. Add the page to
mkdocs.yml nav.

Add a test under tests/unit/ asserting every flag named on the page exists in
the parser — the page must fail CI if the surface moves, not drift silently.

Verify: uv run pytest <your test file>; uv run python scripts/check_docs_drift.py;
uv run mkdocs build --strict; uv run ruff check . && uv run ruff format --check .

Do not change receipt behaviour. If the page cannot honestly describe what the
code does, stop and say so in the PR rather than editing the code to match.