fix(laws): three git detectors were blind to linked worktrees

[ruleofcodedev]

In a linked worktree (git worktree add) <root>/.git is a FILE holding gitdir: …; the shared config and hooks live in the main repository's git directory. Three laws joined .git/hooks and .git/config onto the project root and found nothing:

• Git Hooks Standards — "Git hooks directory missing"
• Branch Protection Standards — "Unable to read Git configuration"
• Git Hook Compliance — "Git hooks directory not found"

A consumer hit this in a worktree whose husky hooks had just blocked a push: the concern was met and the law said otherwise. The same HEAD scored 100/100 in the primary checkout and 90/100 in the worktree.

A new shared resolver asks git (rev-parse --git-common-dir) instead of guessing the layout, and honours core.hooksPath — a second trap, since husky moves hooks to .husky, which makes <gitdir>/hooks the default rather than the answer. A relative hooksPath resolves against the working tree top level, which is what git itself does.

Verified with real git worktree add fixtures: the three laws now score 100/100 from a worktree, identical to the primary checkout.

What this changes

Verdict impact

• No verdict change (docs, tests, refactor, internal)
• Changes verdicts — a detector now catches more, or fewer, real cases
• BREAKING — a default severity, threshold, or config shape changed
  (then: state the before/after values and what a consumer must do)

Evidence

• Proven red: it flags the violation it claims to flag
• Proven green: it passes correct code (no false positive)
• Regression test added under tests/
• detectionLimits updated if what the detector cannot see has changed

Gate

• npm run lint — 0 errors
• npx jest — full suite green
• npm run canary — red/green proven across stacks
• node dist/cli.js audit — RuleOfCode still passes its own law

Notes for the reviewer