fix(registry): use pnpm deploy for monorepo-aware Dockerfile

[mgoldsborough]

Deploy-blocking — make deploy-all ENV=staging against current main fails the docker build on the registry tsc step:

src/routes/auth.ts(3,53): error TS2307: Cannot find module '@nimblebrain/mpak-schemas' or its corresponding type declarations.
... (15 more such errors across routes/, services/, types.ts)

Root cause

#100 switched the registry's @nimblebrain/mpak-schemas dep from ^0.2.0 (published) to workspace:*. That's the right call — it matches the convention every other package in the workspace already uses (cli, sdk-typescript, web), and removes the publish-bump dance every schemas change otherwise required. The ^0.2.0 pin was actually the band-aid: it dodged the Dockerfile problem by pretending the registry wasn't in a monorepo.

The Dockerfile, however, was written single-package and only copied apps/registry/, never any workspace dep source.

The fix: pnpm deploy

pnpm deploy --filter=<pkg> --prod <out> is pnpm's purpose-built solution for "containerize a workspace package": it walks the full dependency closure (workspace + npm), builds a flattened deployable directory, and resolves all workspace:* links by inlining each workspace package's compiled dist/. One COPY in the runtime stage; future workspace deps require no Dockerfile change.

Considered the simpler patch first (COPY packages/schemas/... then pnpm --filter ... build per-package) but rejected it as per-dep band-aid — the next workspace dep added to the registry would need another COPY pair in both stages.

Builder stage

• COPY . . brings the whole monorepo in (kept lean by .dockerignore)
• pnpm install --frozen-lockfile resolves all workspace links
• pnpm --filter @nimblebrain/mpak-registry exec prisma generate writes the generated client
• pnpm --filter @nimblebrain/mpak-registry... build builds registry + every transitive workspace dep (... filter syntax)
• pnpm deploy --filter=@nimblebrain/mpak-registry --prod /deploy flattens everything into /deploy

Production stage

• One COPY --from=builder /deploy ./ brings everything the runtime needs
• Two preserved COPY lines for Prisma's generated .prisma/ folder (lives in the pnpm hoisted store, not carried by pnpm deploy — the one true special case)

.dockerignore (new)

Keeps the build context small — excludes every package's node_modules, dist, .astro, .turbo, .git, .env*, test outputs, editor state.

Test plan

• docker build -f apps/registry/Dockerfile -t mpak-registry:test . — succeeds end-to-end (was failing on tsc)
• docker run mpak-registry:test — boots fully: Prisma initializes, every module loads, Fastify listens on :3200
• Inside-image runtime check: node -e "import('@nimblebrain/mpak-schemas').then(m => console.log(typeof m.ServerDetailSchema))" → object
• Post-merge: make deploy-all ENV=staging from deployments/mpak succeeds end-to-end

Fast-merge candidate.