docs(docker): split dependency install for better layer caching

[bartlomieju]

Rebased onto the 2.8 branch and updated the Dockerfile examples to use deno ci instead of deno install --entrypoint main.ts. deno ci is the new 2.8 install command intended for CI and image builds — it requires a committed lockfile, wipes any stale node_modules, and installs with --frozen semantics, so two builds of the same commit produce the same dependency tree.

For production images, the examples pass --prod --skip-types: --prod skips devDependencies from package.json and --skip-types drops @types/* packages from both deno.json imports and package.json dependencies. Both shrink the resulting image without changing runtime behavior.

The original layer-caching change is preserved: manifests (deno.json, deno.lock, package.json*) are copied before the full source tree so editing source code doesn't invalidate the dependency install layer, in both the basic and multi-stage examples. The DENO_DIR copy in the multi-stage example is untouched — that part of #2935 already landed in #3122.

Ref #2935

[lunadogbot]

Splitting COPY deno.json deno.lock ./ + RUN deno install before COPY . . is the right caching shape — the dep layer only invalidates when deno.json/deno.lock change. COPY --from=builder /deno-dir /deno-dir in the multi-stage example matches DENO_DIR=/deno-dir/ baked into the denoland/deno image, so the runtime cache is preserved.

• nit: last_modified: 2025-12-16 in the frontmatter wasn't bumped — repo convention is to bump it for substantive content changes.
• nit: basic example runs deno install then deno install --entrypoint main.ts — the second resolves everything from main.ts anyway, so the first is purely a caching trick. Worth a one-line comment so readers don't think both are required.
• nit: COPY deno.json deno.lock ./ fails the build if a project has no deno.lock yet. COPY deno.json deno.lock* ./ keeps it working for first-time users.