Serve the CN Token Standard registry HTTP API #21

Objective

Expose the token over the CN Token Standard Registry HTTP API so that standard wallets and the token-standard CLI can discover instruments and obtain the choice contexts they need to transact.

Rationale

The Daml templates are only half the standard. A CIP-0056 registry must also serve instrument metadata and, critically, the choice contexts that let a wallet exercise a factory or instruction choice without knowing anything about our concrete templates. Because LF 2.1 has no contract keys, the service is the only place that can resolve a preapproval contract id or an escrow LockedToken and disclose it to a counterparty. Without it the token cannot be driven by standard tooling at all.

Scope

In scope:

• A self-contained registry/ TypeScript package, separate from the Daml package
• Instrument metadata endpoints: /info, list instruments, get instrument by id
• Transfer factory and transfer-instruction choice-context endpoints
• Allocation factory and allocation choice-context endpoints
• Operator propose-accept admin endpoints, with off-ledger (admin, instrumentId) uniqueness
• A ledger client over the Canton JSON Ledger API v2
• Response validation against the vendored OpenAPI specs in tests

Out of scope:

• Changing any Daml template
• Live-node verification and end-to-end conformance, which belong to the conformance epic
• Authentication and multi-tenant operation

Architecture & technical considerations

• Node with NodeNext ESM, Express 4, vitest, ajv plus js-yaml for schema validation. Every relative import in src/ needs a .js extension.
• The vendored OpenAPI specs are copied into registry/openapi/ and kept byte-pristine. They are the contract for both responses and, later, requests.
• Choice contexts are full fidelity: the direct-transfer path carries the preapproval contract id and discloses the preapproval, the joint allocation cancel carries the expire-lock signal, and accept/reject/withdraw disclose the escrow LockedToken.
• InstrumentConfig payloads expose the id as instrumentId (Text). The standard InstrumentId value type has .admin and .id. Conflating the two is the recurring bug in this area.
• The JSON Ledger API v2 envelope and AnyValue encoding are isolated in ledger.ts and disclose.ts as the single adjustment sites.

Dependencies

Depends on the Daml token model epic. Blocks the conformance and docs epic.

Issue breakdown

• Serve the registry HTTP API over the Canton JSON Ledger API #30 Serve the registry HTTP API over the Canton JSON Ledger API (feat(registry): add the CN Token Standard registry HTTP service #7)

• Production-harden the registry HTTP service #22 Production-harden the registry HTTP service (epic)

• pageSize and pageToken are documented on the instrument list endpoint but ignored by its handler #46 pageSize is documented in the specs but ignored by the list handlers

Acceptance criteria

• Metadata, transfer, allocation, allocation-instruction, and admin endpoints are implemented
• cd registry && npm test is green and every response validates against the vendored OpenAPI schemas
• (admin, instrumentId) uniqueness is enforced off-ledger at accept, with a read-side 409 backstop
• The service package is self-contained and does not modify the Daml package