gitignore: anchor the controller entry so it stops matching cmd/controller/

A bare 'controller' matches directories too, so rg silently skipped
cmd/controller/main.go (false no-caller readings) and new files there needed
git add -f. /controller still ignores the built binary.

CHANGELOG.md

@@ -1,5 +1,17 @@
 ## Changelog
 
+### v0.157.1 — anchor the `controller` .gitignore entry (2026-07-21)
+
+Tooling only; no behaviour change, no rebuild needed.
+
+`controller/.gitignore` carried a bare `controller`, which git matches against DIRECTORIES as well
+as files — so it also matched `cmd/controller/`. Two opposite failure modes came out of that, and
+both manufacture inert seams: ripgrep silently skipped `cmd/controller/main.go`, so a search for a
+setter's caller returned nothing and read as "this is unused" (a false no-caller reading has already
+been recorded once); and genuinely-new files under `cmd/controller/` needed `git add -f` or were
+never committed at all. Anchored to `/controller` + `/controller.exe`, which still ignores the built
+binary at the module root — verified both ways.
+
 ### v0.157.0 — the boot bind gate honours a customer's Stop (R-55) (2026-07-21)
 
 **Your Stop now means Stop across a guest reboot for drive-backed apps too** — the guarantee R-52

controller/.gitignore

@@ -4,8 +4,13 @@ bin/
 *.dll
 *.so
 *.dylib
-controller
+# ANCHORED (leading slash) on purpose: a bare `controller` also matches the DIRECTORY
-controller.exe
+# cmd/controller/, so ripgrep silently skipped main.go and new files there needed `git add -f`.
+# Both directions produce inert-seam mistakes — a grep for a setter finds no caller and reads as
+# "this is unused", and a genuinely-new file never gets committed. Only the built binary at the
+# module root should be ignored here.
+/controller
+/controller.exe
 
 # Test artifacts
 coverage.out