docs(gate): record the ledger-gate coupling where someone can BREAK it, not only where it is relied on

[wshallwshall]

Records a load-bearing coupling where someone can break it, not only where it is relied on. Comment only -- 18 lines added, zero non-comment lines, no behaviour change.

What was missing, which is narrower than it first appeared

ledger_check.py's owns() authorises a ledger number by comparing the worktree that allocated it -- and that only works because the worktree gate forces each session into its own. docs/LEDGER-GATE.md:185 documents that pairing from the dependent's side, ending "The two gates are a pair."

The gate file itself said nothing about it. And the reason it was easy to miss is measurable: "ledger" appears seven times in worktree_gate.ps1, and every one is the opposite relationship -- rule 3c refusing a core.hooksPath repoint, rule 1b refusing a write to alloc/, the pre-commit protection. All of them are this hook protecting the ledger gate's inputs. The dependency runs the other way: owns() relies on rule 1's scope, not on its protection.

Seven mentions of the inverse relationship is precisely why the real one went unrecorded -- including by the author of several of those seven.

Why a comment, and not an item, and not a test

Breaking this does not look like breaking a gate. Widening what rule 1 governs disarms no hook and fails no test. It simply turns owns() into a no-op for the newly-ungoverned paths, and the ledger then merges clean and corrupts silently.

No test can warn about a deliberate design choice, so the warning has to sit at the decision point -- rule 1's own header, where someone about to widen it is already reading. An item would describe the hazard somewhere nobody looks at the moment they create it.

The evidence it cites, rather than the risk it asserts

Commit 341e650d -- the author's own first cut at the rule 1 fix -- widened rule 1 to the whole of .git/mefor-coord/ and thereby exposed alloc/<kind>/<n>.json, so a Write could have forged an allocation that owns() would then authorise. --ci skips that rule entirely.

It was caught by adversarial review, not by any gate, and nothing in the file would have warned its author. That is the gap this closes, from the side that matters.

Verification

0 parse errors; 8 functions with both ConvertTo-WorktreeSlug and Get-SafeForMessage still present as FunctionDefinitionAst; 0 non-ASCII bytes; 239 passed across the 9 runnable gate files. Touches no BACKLOG heading, so no ledger entitlement is involved.

If a conflict appears against the #1041 rule 3d work, it is additive -- this hunk is rule 1's header (:788), that one is rule 3d (:524-570). Keep both.