bug(guards): reach_declarations_test passes locally on a commit CI fails — a local pass is not evidence #17144

Problem

On #17072 head ff296b7142, CI fails:

ReachFloorError: [prompt-injection-detector-strict-mode] floor 2940 sits 304 below
its live population of 3244 tracked backend python files (tests excluded),
which exceeds the declared allowance of 300 (skips=0 + growth=300).
FAILED repo_tests/reach_declarations_test.py::test_every_declared_floor_is_pinned_to_its_population[prompt-injection-detector-strict-mode]

Running that same test against that same commit in a detached worktree passes — twice, in two
separate worktrees (224 passed, then 34 passed for the parametrized floor test alone).

The population data is present locally. In the same worktree, the guard's own discovery command
returns the same number CI reports:

git ls-files -- 'autobot-backend/*.py' | grep -v '_test\.py$' | wc -l   ->  3244

So the guard had the failing number available and did not fail on it.

Why this matters

A guard that passes locally and fails in CI on identical input is worse than one that simply fails:
it converts local verification into false assurance. Working from that local pass, the obvious
conclusion was "the floor is fine, something else in shard 12 is failing" — which is wrong, and
would have sent someone looking for a second, non-existent defect while the real one sat in plain
sight in the error message.

This also undermines the pre-push hook's value for this class of guard: a developer who runs these
tests before pushing gets a green that does not predict CI.

What is NOT the cause

• Main moving under the branch: git log 0f5b45cab..origin/main is empty and behind-ok reports
  behind=0.
• A stale checkout: the worktree was created fresh from origin/issue-17043-17056-approval-consolidation
  and git log --oneline -1 confirmed ff296b7142.
• The discovery command failing outright: it returns 3244 in that worktree.

Unresolved

I did not determine why the guard does not act on the number its own discovery returns. Candidates
worth checking, none confirmed: repo_root()'s lru_cache interacting with worktrees;
reach_declarations_test driving discover against a substitute root (its docstring mentions
being driven against an empty directory for #15826) so the real root is never measured; or
scrubbed_git_env() behaving differently under a worktree than under a plain checkout.

Stating that as unresolved rather than picking the most plausible one — a guessed cause here would
send the fix at the wrong mechanism.

Acceptance criteria

• The reach floor guard produces the same verdict locally and in CI for the same commit,
  demonstrated on ff296b7142 (or a reconstruction of it) failing in both.
• If the divergence is worktree-specific, the guard either works correctly in a worktree or
  refuses to run there with an explicit message — never a silent pass.
• A test asserts the guard fails when the population exceeds floor+growth, driven through the
  same entry point CI uses, so a future vacuous pass is caught.

Notes

Found landing #17072. Related: #17142 (the same floors re-pinned three times in one night) and
#15928 (floors set below their own discovery).