Drop the lint-guard shell scanner, keep the Dockerfile.lint checks (closes #121)

Four reviews found successive ways a shell script could run the host
linter that the hand-written scanner in cmd/vaultik/lintdocker_test.go
did not see. A shell parser cannot be complete, and it is the
machinery-over-fix the workflow rejects. The tree is already right:
script/lint is the only lint entry point and runs golangci-lint only
inside the container; keeping it so is a review matter.

Remove TestNoHostLintPathRemains and every helper and helper-test that
served only it. Keep the plain Dockerfile.lint assertions: pinned image,
config verify before run, and the per-run epoch reaching both steps.
Correct the TODO.md sentence that claimed a test proves no host lint.

Model: opus-4-8

TODO.md

@@ -78,10 +78,11 @@ release" is exactly the contradiction
   into each check command, and a fresh `$(date +%s%N)$$` per invocation
   computed as a bare assignment. `cmd/vaultik/lintdocker_test.go`
   parses both Dockerfiles and both scripts and fails if any part of
-  that is dropped, because every way of losing it is silent. Its
-  host-lint assertion is structural — no script runs `golangci-lint`
-  except through `docker` — rather than a search for the one retired
-  variable name, which nothing could ever reintroduce.
+  that is dropped, because every way of losing it is silent. No test
+  asserts that no script runs the host linter: `script/lint` is the one
+  lint entry point and runs `golangci-lint` only inside the container,
+  and keeping it that way is a review matter, not something a test
+  proves.
 
   The product `Dockerfile` lost its lint stage rather than gaining a
   second linter pin: `make lint` is now `docker build`, so the stage