Install the repo without the Daml toolchain #158

User story / Problem statement

Currently the root package.json carries "postinstall": "npm run setup",
which is scripts/fetch-dep.sh: it wants dpm, a JDK 17+, git and a 123 MB
clone of canton-network/splice, and it takes minutes on a first run. npm runs
a dependency's postinstall during the consumer's install, so anyone
depending on this repository pays for the entire Daml toolchain in order to
start an HTTP service that never reads a DAR. On a machine without dpm the
install does not merely slow down, it fails outright.

Expected outcome

A root npm install compiles the registry service and vendors nothing.
Vendoring the Splice DARs becomes an explicit npm run setup, which is the
command that already did it. A checkout that has never run setup can still
install and build the service.

Acceptance criteria

Install lifecycle

• postinstall is gone from the root package.json
• prepare runs tsc -p registry/tsconfig.json
• A root npm install in a fresh clone creates registry/dist/index.js and
  does not create deps/
• A root npm install succeeds with dpm absent from PATH
• npm run setup still vendors, unchanged

Dependency closure

• The root manifest declares dotenv, express, express-openapi-validator
  and pino as dependencies, at the ranges registry/package.json uses
• The root manifest declares typescript, @types/express and @types/node
  as devDependencies, at those same ranges
• registry/package.json declares @types/node explicitly
• Both lockfiles are regenerated, and npm ci succeeds at the root and in
  registry/

Nothing else moves

• registry/'s own lint, build, suite typecheck and unit suite all still pass

Documentation

• No document claims that a root npm install vendors the Daml dependencies

Alternatives considered

• Guard postinstall so it no-ops during a consumer's install (detecting via
  INIT_CWD, npm_config_global or similar). Rejected: the detection is fragile
  across npm, pnpm and yarn, and it still leaves a script in the consumer's
  install graph that can fail. Deleting it removes the whole class of failure.
• Keep postinstall and tell consumers to install with --ignore-scripts.
  Rejected: that flag also skips prepare, so the consumer gets no build at all.

Technical notes

• tsc reads type declarations that ship inside pino and
  express-openapi-validator, so the runtime dependencies are needed for the
  compile, not only at runtime. A root build with devDependencies alone dies
  with two TS2307: Cannot find module errors. Declaring them in this issue
  rather than a later one is what keeps this one independently green.
• Pin @types/node at the version that already resolves transitively (^26.1.1
  at the time of writing; confirm with
  node -e 'console.log(require("./registry/node_modules/@types/node/package.json").version)').
  registry/src uses node:path, node:url and process, and compiles today
  only because vitest and tsx pull the package in. Pinning a lower major would
  silently change the type surface the existing suites were vetted against.
• registry/tsconfig.json needs no change: outDir and include are relative
  to the tsconfig's own directory, so a root-driven build emits to
  registry/dist exactly as cd registry && npm run build does.
• No CI job runs a root npm install. The daml job calls
  bash scripts/fetch-dep.sh directly, and the registry job installs inside
  registry/. .github/workflows/release.yml also calls fetch-dep.sh
  directly, at lines 148 and 178; its only npm run setup mention is a comment
  describing what a consumer does, which stays true. So deleting postinstall
  changes no workflow behaviour and needs no workflow edit.
• registry/package-lock.json has to be regenerated alongside
  registry/package.json, or the registry CI job's npm ci fails loudly on
  the drift.
• Sites that state or imply that npm install vendors: README.md (three),
  RUNBOOK.md (two), ARCHITECTURE.md (one), CLAUDE.md (three), SPEC.md
  (one). RUNBOOK.md's cd registry && npm install is correct and stays.