[ottonomy]

Closes #44

Stacked on #71 — review and merge that first (or merge the stack together).

Departures

None. All four doc defects named in the ticket are fixed, and the acceptance
test is in place.

Decisions not in the issue

• Where the test lives. test/verify-credential.spec.ts, in a new
  advisory (non-fatal) failures describe block. It drives the public
  verifyCredential with a fake HTTP service returning an empty
  dcc-legacy registry, so trust.registry.issuer is the only failing
  check; it asserts the failure list is exactly that one id, that the check
  is not fatal, that verified is true, and that the trust.registry
  summary has status: 'failure' and hasFailures: true.

• How the API guide's examples were made truthful. The ticket says the
  UI recipe and the worked example must stop showing a registry-only failure
  as verified: false, but not which way to resolve it. Rather than delete
  the failing-verdict illustration, both now show both cases side by side:
  credential 1 fails only advisory checks (registry, and an Open Badges
  semantic check in the recipe) and stays verified: true with
  hasFailures: true on those suites; credential 2 fails
  cryptographic.proof.signature fatally, which is what makes a verdict
  false. The appendix JSON for credential 2 therefore gained the realistic
  "Not run after fatal" skip rows and matching summary entries. A reviewer
  who would rather see a single simpler example can cut credential 2.

• A new ### The top-level verdict subsection was added near the top of
  docs/api/verification-results.md (and linked from the table of contents)
  so the advisory list is stated once and referred to from the recipe and
  the appendix, instead of being repeated three times in full.

• Advisory checks are named by their full ids in the README and API
  guide (trust.registry.issuer, cryptographic.status.list-issuer, …)
  and by their short ids in the TSDoc, matching how each surface already
  refers to checks.

• Two extra timing-guide ids. Besides the
  cryptographic.parsing.parsing.envelope → cryptographic.parsing.envelope
  fix the ticket names, the prose in the TimeService section referred to
  proof.signature and status.bitstring; those are now the full ids the
  code produces, so "every id in the guide is a real one" holds without
  having to argue about prose-vs-example.

• Left alone, deliberately: VerifyCredentialOptions.credential /
  VerifyPresentationOptions.presentation still say "parsed internally via
  Zod". That describes the input and what the verifier does with it (it
  does parse, as a gate), not the returned object, so it is accurate and
  outside the ticket's "nothing calls the returned credential parsed".

Agent-Run: 96643ad2-b7e6-44b0-a51f-a8f6831d5132