Bring the contributor documentation up to date with the shipped system #44

User story / Problem statement

Currently the README describes a repository that no longer exists. It was written
against the initial scaffold and never revised, so the first document a new
contributor reads is actively wrong:

• It says "The current sample is a Canton.TokenForge.Version marker module; real
  templates are added in Plan 01+". There are six templates and seven interface
  instances.
• It says npm test "builds the production package and runs the version-marker
  smoke script". It runs the whole Daml suite.
• Its "What's inside" section never mentions registry/, the TypeScript service
  that is roughly half the repository.
• It leaks internal plan numbering ("Plan 01+", "only built by Plan 05
  conformance") at a reader who has no access to those documents and no reason to
  care.

The rest of the documentation is in better shape but was written before the
single-admin change, and this issue's own original acceptance criteria are stale
in the same way: they ask for an AGENTS.md that already exists as a deliberate
seven-line pointer to CLAUDE.md, for a docs/ARCHITECTURE.md when
architecture.md already sits at the repo root and docs/ is gitignored, and for
documentation of an operator-versus-admin split and a propose-accept governance
gate that #57 deleted.

Expected outcome

A contributor who has never seen the repository can, from the tracked documents
alone, understand what it is, build both packages, run the tests, bring up a local
sandbox, and find the architecture and conformance references. No tracked document
mentions internal plan numbering, and none describes a role or workflow the code
does not have.

Acceptance criteria

README

• "What's inside" covers both Daml packages, registry/, scripts/,
  versions.env, and the tracked docs
• The quick start describes what npm test actually does (both suites), with
  no reference to a version-marker smoke script
• No claim that templates or tests "land in Plan 01+", and no internal plan
  numbering anywhere in the file
• The single-admin model is stated in one sentence: one party is both the
  instrument admin and the registry identity
• The implemented standard interfaces are listed, or the reader is pointed at
  the conformance document for the authoritative list
• Links to architecture.md, RUNBOOK.md, CONFORMANCE.md, and CLAUDE.md
• scripts/build-harness.sh is described as unused by default, without citing
  a plan number

Architecture document

• Describes the single admin party and what authority it carries (signatory of
  InstrumentConfig and every holding, the read party for the service, the
  adminId in /info)
• Covers every core template: Token, LockedToken, InstrumentConfig,
  TokenTransferPreapproval, TokenTransferInstruction, TokenAllocation
• Explains the direct-versus-offer transfer decision and what gates it (an
  in-window, receiver-signed preapproval supplied through the choice context)
• Covers the faucet and the burn-mint factory
• Explains the choice-context pattern, including which contracts each route
  discloses and why the transfer contexts disclose only the escrow
• Carries a scope note stating there are no economics
• Contains no operator role, TokenRegistry, InstrumentConfigProposal,
  propose-accept flow, or /admin/* endpoint

Agent guide

• CLAUDE.md still covers the toolchain, the build and test commands for both
  packages, the hard rules, and the dependency-vendoring prerequisite; drift
  found while checking is fixed
• AGENTS.md stays a pointer rather than a second source of truth

Cold start

• Someone who has not seen the repository follows the README and RUNBOOK on a
  clean checkout and reaches a served instrument without asking a question
• Every correction that run produces is folded back into the documents

Alternatives considered

• Create docs/ARCHITECTURE.md as originally specified. Rejected:
  .gitignore:11 ignores docs/ outright (verified with git check-ignore), so
  the file would be untracked and invisible to everyone else, and architecture.md
  already exists at the root and was refreshed by Update the runbook and architecture doc for the single-admin model #66. Moving the tracked docs into
  a docs/ folder is a separate, deliberate change that would need the ignore rule
  narrowed first.
• Write a standalone agent-facing guide. Rejected: CLAUDE.md is the single
  source of truth by project rule and AGENTS.md deliberately points at it. A
  third document would be a third thing to keep in sync.
• Fold the conformance document into this issue. Rejected: it is Run the CN Token Standard CLI against an instrument and record conformance #43's
  deliverable and depends on running a third-party client. This issue only links it.

Technical notes

• docs/ is gitignored. Every superpowers spec and plan lives there untracked
  on purpose; do not git add -f them, and do not put new tracked documentation
  there.
• A literal quoted in an issue or plan is quoting the code as of when it was
  written. This bit Update the runbook and architecture doc for the single-admin model #66 directly: a brief told the implementer to document an
  error string the seed never throws. Grep the source for every env var name,
  count, choice name, and error message before writing it down.
• The five-versus-seven trap in this specific area: RUNBOOK.md documents five
  template-id environment variables, while architecture.md's "7 interface DARs"
  refers to the Daml data-dependencies and is correct. Do not "fix" one into
  the other.
• The README's "Requirements" and "Bumping Splice" sections are still accurate and
  should be left alone.
• architecture.md was substantially corrected by Update the runbook and architecture doc for the single-admin model #66, so this is a verification
  pass over it rather than a rewrite. Its "Environment Variables" table is the spot
  most likely to have drifted again.

Additional context

Part of #23. CONFORMANCE.md comes from #43; if #43 has not landed, link it as
pending rather than blocking on it.