fix(docker): cargo-chef so tunnel-node builds without BuildKit (#620, #1117)

Fixes #620 — `tunnel-node/Dockerfile` used BuildKit-only `RUN --mount=type=cache` directives, breaking on Cloud Run's `gcloud run deploy --source .` path (the underlying `gcr.io/cloud-builders/docker` builder doesn't enable BuildKit, and `--set-build-env-vars DOCKER_BUILDKIT=1` doesn't flip it on either).

Reworked to use **cargo-chef**: a dedicated planner stage emits `recipe.json` for dependency metadata, a `cargo chef cook` stage builds just the deps in their own Docker layer, the final build stage adds `src/` on top. Docker's regular layer cache handles dependency reuse — warm rebuilds where only `src/` changes still skip the slow crate compile.

## Changes (`tunnel-node/Dockerfile`-only)

- Dropped `# syntax=docker/dockerfile:1` parser directive and all `RUN --mount=type=cache,...` blocks
- Added cargo-chef multi-stage build (`chef` → `planner` → `builder`)
- Pinned `cargo-chef` to exact `0.1.77` with `--locked` for reproducible installs
- Bumped base from `rust:1.85-slim` → `rust:1.90-slim` (cargo-chef's transitive deps require rustc 1.86+; tunnel-node's `Cargo.toml` has no `rust-version` pin so the bump is internal-only)
- Removed `ARG TARGETPLATFORM` per-platform cache-id workaround — Docker's regular layer cache is already arch-scoped

## Non-changes (deliberate)

- `tunnel-node/Cargo.toml` left alone — the old Dockerfile comment claimed "matches MSRV in Cargo.toml" but no `rust-version` field actually exists. The Docker base bump is internal build-env, not a declared MSRV.
- Base image digest pinning left on tag refs — without Renovate/Dependabot to keep digests fresh, pinning trades automatic glibc/openssl/ca-certificates CVE patching for a reproducibility property this repo doesn't currently need.

## Verified locally

- `cd tunnel-node && cargo build --release`: clean (binary side unchanged)
- `cd tunnel-node && cargo test --release`: 36/36
- Local `docker build` couldn't run (daemon not started on the dev machine); the PR author's test plan documents successful build under classic Docker daemon.

Reviewed via Anthropic Claude.

Co-Authored-By: dazzling-no-more <noreply@github.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

tunnel-node/Dockerfile

@@ -1,12 +1,14 @@
-# syntax=docker/dockerfile:1
-#
 # Multi-stage build for the mhrv-tunnel-node service.
 #
-# Build stage compiles a release binary against rust 1.85 (matches MSRV in
+# Build stage compiles a release binary on a recent stable Rust.
-# Cargo.toml). Cargo's incremental build cache is mounted via BuildKit
+# Dependency caching is done via `cargo-chef`: a separate layer cooks
-# `--mount=type=cache` so a `docker build` against an unchanged dependency
+# just the dependencies first, so warm rebuilds where only `src/`
-# tree skips re-downloading + re-compiling crates — first build ~6 min,
+# changes reuse that layer and skip recompiling crates.
-# warm builds ~30 s.
+#
+# This intentionally avoids BuildKit `--mount=type=cache` directives so
+# the Dockerfile builds on classic Docker daemons too — notably Cloud
+# Run's `gcloud run deploy --source .` builder, which does not enable
+# BuildKit (see issue #620).
 #
 # Runtime stage is `debian:bookworm-slim` for libc compatibility (the
 # binary dynamically links against glibc) plus `ca-certificates` so HTTPS
@@ -27,43 +29,28 @@
 # `--health-cmd 'curl -fsS http://localhost:8080/ || exit 1'` on the
 # `docker run` if you want compose-level health gating.
 
-FROM rust:1.85-slim AS builder
+FROM rust:1.90-slim AS chef
+RUN cargo install cargo-chef --locked --version 0.1.77
 WORKDIR /app
-# Copy lockfile so cargo uses pinned versions identically to local builds.
+
+FROM chef AS planner
 COPY Cargo.toml Cargo.lock ./
 COPY src/ ./src/
-# BuildKit cache mounts: cargo's registry/git caches and the target/
+RUN cargo chef prepare --recipe-path recipe.json
-# directory persist across builds, dramatically speeding up rebuilds when
+
-# only application code changes.
+FROM chef AS builder
-#
+COPY --from=planner /app/recipe.json recipe.json
-# `id=...-$TARGETPLATFORM` is load-bearing on multi-arch builds. Without
+RUN cargo chef cook --release --recipe-path recipe.json
-# it, BuildKit defaults to a single shared cache across architectures
+COPY Cargo.toml Cargo.lock ./
-# and the `linux/amd64` + `linux/arm64` jobs race on the same on-disk
+COPY src/ ./src/
-# `/usr/local/cargo/registry/src/.../<crate>/.cargo-ok` extraction. The
+RUN cargo build --release --bin tunnel-node && \
-# second-arriving arch hits `File exists (os error 17)` mid-unpack and
-# the whole multi-arch build fails. Per-platform cache id keeps each
-# arch's cache isolated; warm-build speedup is preserved per-arch.
-# `target` cache is also platform-scoped because target/ holds object
-# files for one ABI and sharing them across arches would just produce
-# misses or, worse, invalid linking.
-ARG TARGETPLATFORM
-RUN --mount=type=cache,target=/usr/local/cargo/registry,id=cargo-registry-${TARGETPLATFORM} \
-    --mount=type=cache,target=/usr/local/cargo/git,id=cargo-git-${TARGETPLATFORM} \
-    --mount=type=cache,target=/app/target,id=app-target-${TARGETPLATFORM} \
-    cargo build --release --bin tunnel-node && \
     cp /app/target/release/tunnel-node /usr/local/bin/tunnel-node
 
 FROM debian:bookworm-slim
-# `ca-certificates` for HTTPS upstream targets; nothing else needed at
-# runtime since the binary is statically linked against musl-equivalents
-# only for the parts that don't touch glibc.
 RUN apt-get update \
     && apt-get install -y --no-install-recommends ca-certificates \
     && rm -rf /var/lib/apt/lists/*
 
-# Non-root runtime user. The service does no filesystem writes outside
-# /tmp, so a static-uid unprivileged user is sufficient and prevents
-# accidental host-FS writes if the container is volume-mounted.
 RUN useradd --system --uid 1000 --no-create-home --shell /usr/sbin/nologin tunnel
 
 COPY --from=builder /usr/local/bin/tunnel-node /usr/local/bin/tunnel-node