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

Dockerfile.lint

@@ -72,11 +72,11 @@ RUN [ -n "$CHECK_EPOCH" ] || exit 1
 # running, and exits 0 reporting `0 issues.` on a tree the real config
 # fails. Demonstrated on this repo at this pin, recorded on
 # https://git.eeqj.de/sneak/vaultik/pulls/114: with a planted
-# over-length line, `script/lint` exits 1 naming the `lll` finding with
-# `linters:` and exits 0 with `linterz:`. A set-but-ineffective config
-# quietly falling back to defaults is precisely the false-green class
-# this gate exists to eliminate, so it must not sit in the gate's own
-# configuration.
+# over-length line, `script/lint` exits 1 naming the `revive` finding
+# with `linters:` and exits 0 with `linterz:`. A set-but-ineffective
+# config quietly falling back to defaults is precisely the false-green
+# class this gate exists to eliminate, so it must not sit in the gate's
+# own configuration.
 #
 # `config verify` catches it, and it does so OFFLINE at this pinned
 # version -- verified, not assumed. Under `docker run --network none`