Re-vendor the canonical files from sneak/prompts at dd4027b (closes #213)

Linting and testing become the lint and test phases of the Dockerfile,
and the build stage depends on both. Dockerfile.lint, CHECK_EPOCH and
the tests that checked them are removed. Every docker build in script/
passes --no-cache, and script/cibuild runs script/bootstrap first. The
image takes its version from the VERSION build arg or git describe, and
still stamps the commit and its date from .git. The golangci-lint
v2.14.0 findings are fixed in the code. The rules in CLAUDE.md move into
AGENTS.md. IsDevVersion now counts "unknown", the version script/docker
stamps outside a git checkout.

Model: opus-5-5

README.md

@@ -726,12 +726,11 @@ regardless of color setting (emoji are not color).
 ## requirements
 
 * Go 1.26 or later
-* Docker, with a reachable daemon, to lint, check, or commit:
-  `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.
+* Docker, with a reachable daemon, to test, lint, check, or commit:
+  `script/test` and `script/lint` build the `test` and `lint` phases of
+  the `Dockerfile`, and `make check` and the pre-commit hook both run
+  them. A `golangci-lint` installed on `PATH` is not a substitute and is
+  never used on a host, whatever its version.
 * S3-compatible object storage (or local filesystem, or rclone remote)
 
 ## development workflow
@@ -770,9 +769,8 @@ them. We provide:
 * `script/projectname` — print the project name (used for the Docker
   image tag)
 * `script/version` — print the version string to bake into the binary.
-  The `Makefile`'s `LDFLAGS` call this, and `script/docker` and
-  `script/cibuild` pass its output to the image build. See
-  [releasing](#releasing) for the rules.
+  The `Makefile`'s `LDFLAGS` call this. See [releasing](#releasing) for
+  the rules.
 * `script/install-goreleaser` — install the pinned `goreleaser` into
   `.tool/bin` from a sha256-verified release archive. Idempotent, and
   called by `script/bootstrap`; the release workflow calls it directly
@@ -785,97 +783,52 @@ them. We provide:
   nothing else on the release runner does. `actions/setup-go` is not
   used because it verifies the downloaded toolchain against no value in
   this repo. Bumping Go edits `go.mod`, the checksum in this script, and
-  the `Dockerfile` `golang` digest together.
+  the two `golang` digests in the `Dockerfile` together.
 * `script/release` — cross-compile and publish the release artifacts
   with the pinned `goreleaser`. Refuses a `goreleaser` on `PATH` whose
   version is not the pinned one, on the same reasoning as `script/lint`.
 * `script/release-snapshot` — the same build with no publishing and no
   tagging, into `./dist`
-* `script/test` — run the test suite (verbose rerun on failure). This
-  runs *everything*: there is no separate integration target and no
-  build-tagged subset held back, so the full round-trip tests in
-  `internal/vaultik/integration_test.go` run on every invocation. It
-  passes `-count=1`, which disables Go's test result cache. That is
-  deliberate and it is not free: on this repo's suite it costs about 11
-  seconds on every repeat run (measured, back to back: 0.4s cached
-  versus 11.6s with `-count=1`). That is the price of the run meaning
-  anything, because without it an unchanged package prints
-  `ok <pkg> (cached)`, which is indistinguishable from a package that
-  really ran, so the whole suite can report a full set of `ok` lines in
-  under half a second having executed nothing. The `-timeout` is a hang
-  backstop rather than a performance budget — it applies per test binary
-  to test execution only, not to compilation — and is set well above the
-  slowest package's measured runtime. Its 120s value deliberately
-  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` — 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/test` — run the test suite by building the `test` phase of
+  the `Dockerfile` (verbose rerun on failure). This runs *everything*:
+  there is no separate integration target and no build-tagged subset
+  held back, so the full round-trip tests in
+  `internal/vaultik/integration_test.go` run on every invocation. The
+  90s `-timeout` is a hang backstop rather than a performance budget; it
+  applies per test binary, to test execution only.
+* `script/lint` — lint by building the `lint` phase of the
+  `Dockerfile`, which runs `golangci-lint config verify` and then
+  `golangci-lint run --config .golangci.yml ./...` as build steps in
+  the digest-pinned `golangci-lint` image. Nothing lints on the host.
+  That `FROM` line is the only pin of the linter version, and it changes
+  in the same commit as a re-vendored `.golangci.yml`.
 * `script/lint-fix` — apply the linter's autofixes (rewrites files),
-  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.
+  using the same pinned image, parsed out of the `lint` phase's `FROM`
+  line. 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/fmt-check` — check formatting (read-only). It runs `gofmt` on
+  the host.
 * `script/check` — run `script/test`, `script/lint`, and
-  `script/fmt-check`. This is authoritative *because* `script/lint`
-  builds `Dockerfile.lint`: a local `make check` and CI cannot disagree
-  about lint findings.
+  `script/fmt-check`.
 * `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. 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.
-  `.gitea/workflows/check.yml` runs it on every push to `main` and
-  `next` and on every pull request against either.
+  `script/projectname`, stamped with the version
+  `git describe --tags --always --dirty` gives on the host, or `unknown`
+  outside a git checkout. The image's build stage depends on the `lint`
+  and `test` phases, so this lints and tests too.
+* `script/cibuild` — CI entrypoint: runs `script/bootstrap`,
+  `script/check`, and then the same image build as `script/docker`.
+  `.gitea/workflows/check.yml` runs it on every push.
 
-  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 `docker build -f Dockerfile.lint .` that supplies no `CHECK_EPOCH`
-  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 the lint layer from cache, execute nothing, and still exit
-  0. `Dockerfile.lint` 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. The product
-  `Dockerfile` has no such guard, because a plain `docker build .` must
-  succeed: without `CHECK_EPOCH`, rebuilding an unchanged checkout
-  replays its check layers from cache. Use `script/lint`,
-  `script/docker` or `script/cibuild`, which pass the arg, when the
-  checks must run.
+  Every `docker build` in these scripts passes `--no-cache`, because on
+  an unchanged tree a cached check layer is replayed without running and
+  the build still exits 0. A plain `docker build .` is therefore no
+  evidence that the checks ran. The cost is that `script/cibuild` runs
+  the `lint` and `test` phases twice: once in `script/check` and again
+  in the image build.
 * `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
@@ -887,8 +840,8 @@ them. We provide:
 
 The version a binary reports comes from git, not from a constant in a
 file. It is `git describe --tags --always --dirty`, which
-`script/version` runs for the `Makefile`, `script/docker` and
-`script/cibuild`:
+`script/version` runs for the `Makefile`, and `script/docker` and
+`script/cibuild` run themselves:
 
 * `HEAD` is exactly on a tag → that tag, such as `v1.0.0`.
 * a commit after a tag → `<tag>-<N>-g<short sha>`.
@@ -900,14 +853,15 @@ A `docker build .` of a clone, with no build arguments, runs the same
 `git describe` (without `--dirty`) on the `.git` in its build context,
 so it stamps the same value for a clean commit; the build fails if the
 context carries `.git` and no version comes out. A binary built without
-git metadata reports `dev`.
+git metadata reports `dev`, or `unknown` when `script/docker` or
+`script/cibuild` built it outside a git checkout.
 
 `goreleaser` stamps a release binary with the tag minus its leading
 `v`, so the tag `v1.0.0` produces `vaultik 1.0.0`, matching the archive
 name `vaultik_1.0.0_linux_amd64.tar.gz`. `goreleaser --snapshot` stamps
 `dev-<12 chars of the commit sha>` rather than inventing the next patch
 number. `vaultik version` calls a build a development build when its
-version is `dev`, `dev-<sha>`, the short commit sha or
+version is `dev`, `unknown`, `dev-<sha>`, the short commit sha or
 `<tag>-<N>-g<short sha>`, with or without `-dirty`; only a plain tag,
 such as `v1.0.0` or `1.0.0`, is a release. If `script/version` cannot
 be run at all, `make` stops with an error instead of building an