Prove the published package installs and runs #161

User story / Problem statement

npm run smoke proves the built DAR is consumable by a package that
data-depends on nothing else. There is no equivalent for the npm package, so
nothing in this repository exercises what a consumer actually receives. The
failures that would reach a consumer are exactly the ones a green build cannot
see: a file the manifest failed to pack, a runtime import declared in the wrong
manifest, a module-system mismatch, a bin pointing at nothing. Every one of
those leaves the existing checks green.

Expected outcome

One command packs the package, installs it into a scratch consumer outside the
repository, and runs the linked bin, with no participant and no Daml toolchain
involved.

Acceptance criteria

• npm run smoke:registry exists and runs
  scripts/registry-install-smoke.sh
• It asserts the tarball carries the bin target and all four OpenAPI specs,
  before anything is installed
• It installs the tarball into a scratch consumer created outside the
  repository
• It asserts that an executable bin was linked
• Run with no configuration, the bin exits 1 and names LEDGER_API_URL
• Run with a complete environment pointing at a closed port, the service
  listens, answers GET /healthz with 200, answers
  GET /registry/metadata/v1/info with 200, and exits 0 on SIGTERM
• Temporary directories and the background process are cleaned up on exit,
  including on failure
• Each assertion is demonstrated by a mutation that reddens it

Alternatives considered

• Install the git dependency directly
  (npm install github:BootNodeDev/canton-token-forge#<ref>). Rejected as the
  primary check: the repository is private, so it needs credentials, and it
  cannot test an unmerged branch. npm pack runs prepare the same way a git
  install does, so the local pack exercises the same build.
• Run the check against a live sandbox. Rejected: it would make the check
  depend on a participant, and the boot's tolerance of an unreachable ledger is
  precisely what allows a participant-free run.

Technical notes

• The boot tolerates an unreachable participant on purpose. Only two
  participant answers are fatal, PACKAGE_NAMES_NOT_FOUND and
  NO_TEMPLATES_FOR_PACKAGE_NAME_AND_QUALIFIED_NAME, both attributable to our
  own configuration. A refused connection is neither, so the template id check
  warns, the admin party check leaves its verdict undecided rather than false,
  and the boot continues. That is the property this check rests on. If the
  tolerance is ever removed, this script fails loudly rather than passing
  silently.
• GET /healthz proves nothing about the OpenAPI specs.
  express-openapi-validator reads its spec lazily, so a service carrying no
  specs at all boots fine and answers /healthz 200; the failure surfaces as
  500 openapi.validator: spec could not be read on the first API request.
  GET /registry/metadata/v1/info is the cheapest request that crosses one of
  the validators and answers from configuration alone, so it needs no ledger.
  Assert that and the four YAML entries in the archive listing, since a
  single deleted spec would otherwise be invisible to a single request.
• The configuration error goes to stdout, not stderr. The logger writes to
  fd 1. An assertion on stderr passes vacuously.
• The scratch consumer has to live outside the repository, or npm walks up and
  resolves against the root manifest instead of the installed package.
• Mutations worth running, all of which must redden: restore dist to
  registry/.gitignore; delete a runtime dependency from the root; drop
  registry/openapi from files; delete one YAML from the tree; point bin at
  a different module; set the root type back to commonjs.