fix(security): keep the git checkout out of the published image

[IKatsuba]

Problem

The Dockerfile used COPY . . and the repository had no .dockerignore, so the whole build context landed in an image layer — including .git.

actions/checkout defaults to persist-credentials: true, which writes the job's ephemeral GITHUB_TOKEN into .git/config:

[http "https://github.com/"]
	extraheader = AUTHORIZATION: basic <base64 x-access-token:TOKEN>

So every published image carried that token, readable by anyone who pulled the image while the token was still valid — a window running from the image push to the end of the publish job. In that window the token grants packages: write on ghcr.io/ikatsuba/* (the publish job scopes its permissions, so it is not the full default set).

Confirmed present in ghcr.io/ikatsuba/nx-cache-server:main. Tokens in already-published images are expired, so there is nothing to rotate.

The same COPY . . also shipped .env.local, the test suites, .github/, editor configs, and — on any build after #11 — the TLS test fixtures including src/fixtures/tls/key.pem.

Fix

• Dockerfile — copy only deno.json/deno.lock (ahead of deno install, which also keeps the dependency layer cached) and src/index.ts.
• .dockerignore (new) — deny-all plus an allow-list of those same paths, so a future COPY . . cannot reintroduce the leak.
• .github/workflows/main.yml — persist-credentials: false on all five checkout steps. No job needs git credentials after checkout; helm-publish authenticates to GHCR explicitly.

Verification

• Built the image: /app contains only deno.json, deno.lock, src/index.ts. A grep across the filesystem for extraheader and the test AWS key returns nothing.
• Container starts and GET /health returns 200.
• deno fmt --check and deno lint pass.

Reported privately by email. Follow-up worth doing separately: add a SECURITY.md so reports have a documented channel.