fix(dockerfile): replace monorepo COPY paths with standalone npm install

[toon-backlog-bot]

Summary

• Rewrites Dockerfile.dvm to work in the standalone repo — removes all monorepo COPY paths (packages/*/package.json, pnpm-workspace.yaml, pnpm-lock.yaml, patches/, docker/) that don't exist here.
• Replaces the pnpm workspace install with a plain npm install against the root package.json (all @toon-protocol/* deps come from npm).
• Replaces the pnpm workspace build (pnpm -r --filter @toon-protocol/...) with a direct esbuild invocation on src/entrypoint-dvm.ts.
• Aligns --external flags with esbuild.config.mjs: @ardrive/turbo-sdk, arweave, better-sqlite3, plus @libsql/client/libsql (connector's claim SQLite store) and the connector's requireOptional() packages.
• Replaces the pnpm-store cherry-pick of runtime externals with npm install in /tmp inside the builder stage (build tools available there).
• Drops the index.cjs PetBrain stub (was for kind:5250 Dungeon DVM; not in this image).
• Removes the stale follow-up notes from CLAUDE.md and README.md.

Deviations from Agent Assessment plan

None — the plan maps directly to the changes made.

Known dependency

docker build requires all deps in package.json to be resolvable from npm. The current package.json lists @toon-protocol/mill@^0.1.0 which is not yet on the public registry; this same issue is addressed by PR #9's package.json cleanup. The Dockerfile is structurally correct once PR #9 (or equivalent package.json cleanup) lands, or if the CI runner has private registry access.

Verification

# No monorepo COPY paths remain:
grep -n "pnpm-workspace\|pnpm-lock\|packages/\|docker/package\|patches/\|pnpm -r" Dockerfile.dvm
# → (no output)

# npm install in this environment fails on @toon-protocol/mill (private pkg, not yet public)
# Full docker build requires the npm registry to resolve that dep — see Known dependency above.

Closes #13

[ALLiDoizCode]

Two blocking issues; the structural simplification is otherwise sound and a clear improvement over the monorepo-COPY approach.

1. Builder stage npm install fails on @toon-protocol/mill@^0.1.0 — PR is not self-contained

package.json line 22 lists @toon-protocol/mill@^0.1.0 as a dependency. The package is not on the public npm registry, so the builder-stage RUN npm install --ignore-scripts will fail unconditionally, making the Dockerfile non-functional as written.

The PR acknowledges this depends on PR #9, but that creates a broken main between merging this PR and merging #9. Options:

• Include the package.json cleanup (remove @toon-protocol/mill or move it to an optional dep) in this PR.
• Block this PR on PR #9 and merge them atomically (rebase or merge #9 first).
• Gate the CI job with a continue-on-error note — not ideal, but at least doesn't break main.

2. Runtime externals installed without version pins — non-deterministic image

RUN cd /tmp && npm init -y && \
    npm install --omit=dev \
      better-sqlite3 \
      @ardrive/turbo-sdk \
      arweave \
      @libsql/client \
      libsql && \

No lockfile, no version constraints. Every docker build can pull different patch/minor versions from the registry, making images non-reproducible across CI runs, local builds, and production deployments. The old Dockerfile pinned @libsql/client@0.14.0 libsql@0.4.7 @ardrive/turbo-sdk@1.40.2; the new one should pin all five packages to the versions actually verified during development. Supply-chain wise, an unpinned npm install in a Dockerfile is a known risk vector.

Fix: add explicit version pins to the install line, e.g.:

    npm install --omit=dev \
      better-sqlite3@9.x.x \
      @ardrive/turbo-sdk@1.40.x \
      arweave@1.15.x \
      @libsql/client@0.14.x \
      libsql@0.4.x && \

(Fill in the versions that the builder-stage npm install resolves once issue #1 is fixed.)

---

Everything else looks correct:

• The "--banner:js=..." quoting change is shell-equivalent to the old --banner:js="..." form.
• Dropping fastify/@fastify/cors/@noble/curves from --external is intentional and correct — esbuild.config.mjs ties those to the toon-client entrypoint, not the DVM one.
• arweave as an explicit external and explicit runtime install is correct given the dynamic import('arweave') in createTurboAdapter.
• Non-root user, two-stage build, VOLUME/HEALTHCHECK all carry over correctly.
• The index.cjs PetBrain stub removal is valid — kind:5250 is gone from this image.

[toon-backlog-bot]

Addressed both blocking issues in commit 7312d0e:

Issue 1 — @toon-protocol/mill not on npm
Removed @toon-protocol/mill@^0.1.0 from package.json. Confirmed it's the only @toon-protocol/* package missing from the public registry (bls, client, connector, core, relay, sdk all resolve). The builder-stage npm install is now self-contained without depending on PR #9.

Issue 2 — unpinned runtime externals
Pinned all five packages in the /tmp npm install block:

• better-sqlite3@9.6.0 — latest Node 20-compatible v9.x
• @ardrive/turbo-sdk@1.40.2 — matches the version the old Dockerfile had pinned
• arweave@1.15.7 — latest satisfying turbo-sdk's ^1.15.1 peer constraint
• @libsql/client@0.14.0 — matches Dockerfile.mill/town precedent
• libsql@0.4.7 — same

[ALLiDoizCode]

Superseded by #18, which landed the standalone Dockerfile fix on main (Dockerfile.dvm → Dockerfile.store, already building against the carved single-package repo). Dockerfile.dvm no longer exists, so this diff no longer applies. Closing.