chore: build the registry on install instead of vendoring the Daml deps

[lmcorbalan]

Summary

Closes #158

The root postinstall ran scripts/fetch-dep.sh, so anyone depending on this repository paid for a 124 MB clone of canton-network/splice in order to start an HTTP service that never reads a DAR. prepare replaces it: a root install now compiles the registry service and vendors nothing.

Changes

• package.json: postinstall removed, prepare runs tsc -p registry/tsconfig.json, and the registry's four runtime and three dev dependencies move to the root.
• registry/package.json: declares the @types/node it already resolved transitively. Both lockfiles regenerated.
• Docs: five documents plus one scripts/fetch-dep.sh comment now name npm run setup where they credited postinstall.

Acceptance criteria

• All eleven from the issue are met. One does not discriminate: a root npm install already succeeded with dpm absent, because fetch-dep.sh never needed it.

Test plan

Automated tests

Registry lint, build, suite typecheck and unit suite: 205 tests in 10 files, all passing.

Manual verification

In a fresh clone with dpm off PATH, npm install and npm ci both exit 0 in 2s, emit 16 files to registry/dist and create no deps/; the built service starts and exits 1 on its own configuration error. The same install on main takes 10s and vendors 124 MB with no build. npm run setup still vendors unchanged. Two mutations red it: prepare pointed at a missing tsconfig, and the root manifest without pino and express-openapi-validator.

Breaking changes

A checkout no longer vendors deps/ as a side effect of npm install. Run npm run setup before any Daml build.

Checklist

• Self-reviewed my own diff
• Tests added or updated
• Docs updated (if applicable)
• No unrelated changes bundled in

Screenshots

None.