docs: make first TRACE record reproducible and clarify verification

[imran-siddique]

Readers could mistake software signatures for proof of execution, and the quickstart generated multiple keys without a clear verification path. The homepage now leads to one complete local example: sign synthetic claims, retain the verifier key, verify in another process, and reject tampering.

The tutorial installs from source because published 0.9.0 bundles a schema that still requires transparency for an unanchored record. It explains the separate hardware and registry checks, keeps existing section anchors, and adds a test that executes both documented Python blocks. The existing artifact-ignore test now expects the saved public key and record; the example no longer saves a private key. Homepage-only changes now trigger the docs deployment workflow.

Validation:

• Tutorial execution, Ruff, and house-style checks pass.
• MkDocs build succeeds. Existing link diagnostics elsewhere remain.
• Windows suite: 1,162 passed, 1 skipped, 5 failed. All five failures reproduce on the unchanged base a1ea835: four byte-for-byte fixture generation checks and the schema path separator check. Linux CI is the merge gate.

No runtime or schema changes. Visual deployment verification remains pending merge.

[lywinged]

Approving at 4775873.

I ran the tutorial rather than only reading it. Extracted both python blocks to files, ran them in a scratch directory, and the first one's output matched the page's expected output block byte for byte. The second verified the saved record in a separate process against the retained key, and the changed record raised InvalidSignature as the page says it will. Full suite 1167 passed and 1 skipped on Linux at this head, with ruff, tools/check_dashes.py and mypy clean.

The install note earns its place. I installed agentrust-trace==0.9.0 from PyPI and validated the record this page produces against it: it fails with 'transparency' is a required property. The published schema's top level still requires that member and the checkout's no longer does, so pointing readers at the source install is load-bearing rather than a formality.

Two suggestions, neither blocking.

The paths list wants examples alongside index.md. The deploy step copies that tree into the build directory and the site serves what lands there: https://trace.agentrust-io.com/examples/delegation-link/01-valid-single-hop.json answers 200. The trigger list does not name it, so a change touching only that tree publishes nothing. Nothing is stale today, since the site serves every vector currently in the corpus, and workflow_dispatch covers the manual case. It is the same omission the added line fixes, one entry over.

The new test could pin the page's expected output rather than two substrings of it. That block sits in the file the test already reads. I changed one line of it and left the scripts alone: the test still passes.

Not this PR. mkdocs build already reports one case of this: Doc file 'docs/crosswalks/acta-decision-receipts.md' contains a link to 'examples/action-receipts/README.md' which is excluded from the built site. The cause is the bare README.md in exclude_docs, which in that syntax excludes a README at any depth, so that link answers 404 on the site while the page carrying it answers 200. The same build prints ten warnings about targets missing from the site, seven of them links and three nav entries, so the build log looks worth a pass of its own.

Tool-assisted: the runs and this write-up.