Lint in a container as a build step, via Dockerfile.lint (closes #113)

Every lint run now happens inside its own container, invoked through
script/lint, and linting is a build step rather than a container
command: a successful build of the new root Dockerfile.lint IS a clean
lint. That shape also works where the docker daemon is remote and bind
mounts are impossible.

Its FROM line -- golangci/golangci-lint:v2.12.2, pinned by digest -- is
now the only pin of the linter version in this repo.

A container per run has its own lint cache and its own golangci-lint
lock, both discarded with it, so neither cross-worktree contamination
nor lock contention exists any more. The machinery that defended
against them is therefore gone: the per-worktree cache directories, the
lock-retry loop, and script/lint-audit, which existed to catch findings
replayed from a cache that no longer exists. So is the host lint path
in its entirety -- the native escape hatch, its version detection, and
VAULTIK_LINT_IN_CONTAINER in both script/lint and the Dockerfile.
Nothing lints on the host, at any version.

A cached build lints nothing, so the CHECK_EPOCH mechanism the product
Dockerfile already used is what makes a green mean something:
ARG CHECK_EPOCH with no default, placed below the module layers so
dependency caching survives, a `RUN [ -n "$CHECK_EPOCH" ] || exit 1`
guard so a build that withholds the arg fails instead of replaying, and
the value expanded into the lint command itself. script/lint computes
`epoch="$(date +%s%N)$$"` as a bare assignment on its own line, because
inline in the argument a failing substitution does not abort under
`set -eu` and yields a constant empty epoch -- which is exactly the
false green being prevented.

The product Dockerfile loses its lint stage rather than gaining a
second linter pin. That stage ran `make lint`, which is now
`docker build`: docker-in-docker inside a BuildKit step with no daemon.
Calling golangci-lint directly there instead would have meant two
independently bumpable digests for one tool. `make fmt-check` moves
beside `make test` in the builder stage, and script/cibuild now builds
Dockerfile.lint and then Dockerfile, each with its own fresh epoch,
failing on either. Consequence, stated in comments rather than left to
be discovered: script/docker builds the product image only and no
longer lints; script/check and script/cibuild are the gates.

`golangci-lint config verify` runs as its own epoch-keyed layer, above
the lint. It is not belt-and-braces: `golangci-lint run` rejects a
config it cannot PARSE but silently IGNORES an unknown top-level KEY.
Renaming .golangci.yml's `linters:` to `linterz:` -- one character --
discards `default: all`, the disable list and every threshold, leaves
only the small default linter set running, and exits 0 reporting
`0 issues.` on a tree the real config fails with an lll finding, in a
run whose lint layer demonstrably executed. That is a set-but-
ineffective config falling back to defaults instead of failing loudly,
sitting in the gate's own configuration. `config verify` catches it and
does so with the network genuinely off at this pin: under
`docker run --network none` against the pinned digest it exits 0 on
this repo's config and exits 3 on the `linterz:` variant. It is keyed
on CHECK_EPOCH like the lint itself, because a cached validation
validates nothing.

script/lint-fix is kept, reimplemented as a bind-mounted
docker run against the image parsed out of Dockerfile.lint -- a build
step cannot write fixes back to the worktree -- and its header states
outright that it is a developer convenience, never a gate, and needs a
local daemon.

cmd/vaultik/lintdocker_test.go parses both Dockerfiles and both scripts
and fails if any part of the mechanism is dropped: the digest pin, the
defaultless ARG below `go mod download`, the emptiness guard, the
expansion of the epoch into each check command, the bare per-invocation
epoch assignment in both scripts, cibuild building both files, the
config verification running before the lint, and -- structurally, not
by searching for one retired variable name -- that no script invokes
golangci-lint except through docker. Every one of those losses is
silent: the build still exits 0 and nothing is checked, which is why
they are asserted rather than trusted. The scanner behind the last of
those has its own test, because a structural check that goes blind
passes on every tree, including a broken one.

script/lint takes no arguments now, and says so instead of dropping
them: a build step has no command line to pass linter flags to.

README.md

@@ -598,10 +598,11 @@ regardless of color setting (emoji are not color).
 
 * Go 1.26 or later
 * Docker, with a reachable daemon, to lint, check, or commit:
-  `script/lint` runs the digest-pinned `golangci-lint` image declared by
-  the `Dockerfile` lint stage, and `make check` and the pre-commit hook
-  both run it. A `golangci-lint` installed on `PATH` is not a substitute
-  and is never used on a host, whatever its version.
+  `script/lint` lints by building `Dockerfile.lint`, which runs the
+  digest-pinned `golangci-lint` image as a build step, and `make check`
+  and the pre-commit hook both run it. A `golangci-lint` installed on
+  `PATH` is not a substitute and is never used on a host, whatever its
+  version.
 * `sqlite3` CLI, which the test suite shells out to
 * S3-compatible object storage (or local filesystem, or rclone remote)
 
@@ -671,46 +672,69 @@ them. We provide:
   diverges from the 30s `REPO_POLICIES.md` mandates; the reasoning is in
   the comment in the script, and issue #101 proposes amending the policy
   text.
-* `script/lint` — run `golangci-lint run ./...` at the exact version CI
-  uses, by running the digest-pinned `golangci-lint` image declared by
-  the `Dockerfile` lint stage (requires Docker; it fails loudly rather
-  than falling back to a differently versioned `golangci-lint` on
-  `PATH`). That `FROM` line is the single source of truth for the linter
-  version — bump it there and nowhere else.
+* `script/lint` — lint by building `Dockerfile.lint`, which runs
+  `golangci-lint run --config .golangci.yml ./...` as a build step
+  inside the digest-pinned `golangci-lint` image, so a successful build
+  *is* a clean lint. Nothing lints on the host, at any version, ever;
+  the script requires Docker and fails loudly rather than falling back
+  to a `golangci-lint` on `PATH`. That `FROM` line is the single source
+  of truth for the linter version — bump it there and nowhere else.
+
+  It takes no arguments, because a build step has no command line to
+  pass flags to, and it passes a fresh `--build-arg CHECK_EPOCH` on
+  every invocation so the lint layer cannot be replayed from cache (see
+  `script/cibuild` below for what that mechanism defends against). To
+  watch the linter execute, run it as
+  `BUILDKIT_PROGRESS=plain script/lint` and check that the lint layer
+  says `RUN … golangci-lint` rather than `CACHED`.
+
+  One container per run means one lint cache and one `golangci-lint`
+  lock per run, both private to it and discarded with it, so concurrent
+  runs on one host cannot contaminate or block each other.
 * `script/lint-fix` — apply the linter's autofixes (rewrites files),
-  using the same pinned linter
+  using the same pinned image, parsed out of `Dockerfile.lint`. It
+  cannot be a build step, because fixes have to land in the worktree, so
+  it bind-mounts the tree into a `docker run` and therefore needs a
+  *local* daemon. It is a developer convenience and never a gate: no
+  gate reads its exit status. Run `make lint` afterwards to find out
+  whether the tree is clean.
 * `script/fmt` — format all code (writes)
 * `script/fmt-check` — check formatting (read-only)
 * `script/check` — run `script/test`, `script/lint`, and
-  `script/fmt-check`. This is authoritative *because* `script/lint` uses
-  the pinned linter: a local `make check` and CI cannot disagree about
-  lint findings.
+  `script/fmt-check`. This is authoritative *because* `script/lint`
+  builds `Dockerfile.lint`: a local `make check` and CI cannot disagree
+  about lint findings.
 * `script/docker` — build the Docker image tagged via
   `script/projectname`. Passes a fresh `--build-arg CHECK_EPOCH` for the
   same reason `script/cibuild` does, so a local image build cannot be
-  green on checks it replayed from cache.
-* `script/cibuild` — CI entrypoint: `docker build` (the `Dockerfile`
-  runs `make fmt-check` and `make lint` in its lint stage and `make
-  test` in its builder stage). This is the full CI-equivalent gate — it
-  runs the checks in the same containers CI does, from a clean copy of
-  the tree, so it also catches anything that depends on host state. It
-  passes a fresh `--build-arg CHECK_EPOCH`, unique per invocation, which
-  the `Dockerfile` declares immediately above the check `RUN`s in both
-  stages and expands into each check command. Those layers are keyed on
+  green on checks it replayed from cache. It builds the *product* image
+  only, and the product `Dockerfile` has no lint stage, so it does not
+  lint: a green here means formatted, tested, and it compiles.
+* `script/cibuild` — CI entrypoint, and the full gate. Two builds, in
+  order: `Dockerfile.lint` (the linter, as a build step) and then
+  `Dockerfile` (`make fmt-check` and `make test` in its builder stage,
+  then the product image). Either failing fails the script. It runs the
+  checks in the same containers CI does, from a clean copy of the tree,
+  so it also catches anything that depends on host state.
+
+  It passes a fresh `--build-arg CHECK_EPOCH` to each build, unique per
+  invocation, which both files declare immediately above their check
+  `RUN`s and expand into each check command. Those layers are keyed on
   that value, so a new value re-runs them even on a byte-identical tree,
   and a green from this script means the checks executed. Dependency and
   module layers sit above the `ARG` and still cache, so a build is not
   cold.
 
-  A build that supplies no `CHECK_EPOCH` — a bare `docker build .` —
-  fails rather than lying. An unset `ARG` is an empty string and an
-  empty string is a stable cache key, so without a guard such a build
-  would serve all three check layers from cache, execute nothing, and
-  still exit 0. Each check stage therefore asserts the value is
-  non-empty before running anything, and because failed steps are never
-  cached that assertion fires on every invocation rather than once. Use
-  `script/cibuild` (or `script/docker`, which passes the same arg); a
-  bare `docker build .` is now a loud error.
+  A build that supplies no `CHECK_EPOCH` — a bare `docker build .` or
+  `docker build -f Dockerfile.lint .` — fails rather than lying. An
+  unset `ARG` is an empty string and an empty string is a stable cache
+  key, so without a guard such a build would serve every check layer
+  from cache, execute nothing, and still exit 0. Each file therefore
+  asserts the value is non-empty before running anything, and because
+  failed steps are never cached that assertion fires on every
+  invocation rather than once. Use `script/lint`, `script/docker` or
+  `script/cibuild`, which pass the arg; a bare `docker build` is a loud
+  error.
 * `script/precommit` — pre-commit gate: `go mod tidy` + `go fmt` (must
   not change files), then `script/check`
 * `script/install-precommit` — install the git pre-commit hook that