[Ticket]: The LoC ratchet does not ratchet — loc-baseline.json is raised by the same PR that grows the file

### Type

Bug

### Summary

The LoC ratchet does not ratchet. `.github/loc-baseline.json` is a committed file that a PR can edit **in the same commit that grows the code**, so every grandfathered file's ceiling rises to meet it. The gate has never refused anyone.

### Intent

`loc-gate.sh` states the contract: grandfathered files "may be touched but **must not grow** past the count recorded there." `generate-baseline.sh:8` states the intent even more plainly — regenerate after a real split, *"never to paper over a file that grew."*

Neither is enforced by anything. The result is a green check that certifies the opposite of what it claims, which is worse than no gate: epic #162's success metric is "the baseline is published and **trending down**", and it has only ever trended up while CI stayed green.

### Current Behavior

Verified on `origin/main` — `app/governance-auth/src/otel.rs`'s recorded ceiling, in commit order:

| Commit | Baseline |
|---|---|
| `45bd4e4` | 1522 |
| `ea244f7` | 1580 |
| `35f5173` | 1671 |
| `86f2fbf` | **1837** |

Current actual: **1837**. Every commit that touched a grandfathered entry raised it — including `9ec65fd`, whose title is literally *"chore(loc-gate): raise the credential.rs baseline after the cratestack rename"*. `cache.rs` went 602 → 719 the same way (#235 counted three raises).

⚠️ **The same defect exists in `lightbridge-authz`**, whose gate is a direct port (`c42079c`, "port from lightbridge-governance"). There, `crates/lightbridge-authz-rest/src/lib.rs` is grandfathered at **4528** — its own burn-down ticket #519 argues from a 4,068 baseline that no longer exists. Fix both, or the port re-imports the hole.

### Expected Behavior

A baseline entry can go **down** or disappear. It cannot go up without an explicit, visible, approved override.

### Acceptance Criteria

1. A CI step diffs `.github/loc-baseline.json` against the **base branch** and fails on any increased value or any new key.
2. The failure message names the file, both numbers, and how to override.
3. An override exists and is deliberate — a `loc-baseline-raise` PR label requiring maintainer approval — because a legitimate raise does occur (a rename, a vendored file). It must be a decision, not a side effect.
4. A test proves the guard: a PR that raises an entry without the label **fails**; the same PR with the label passes. Write it to fail first.
5. `#162`'s success metric is re-stated in absolute terms: **entry count and summed lines in `loc-baseline.json` strictly decrease**. Delete the "% of codebase" framing — the denominator grew by 74 files and ~11k lines since 2026-08-27, moving that percentage 21 points with zero burn-down.

### Out of Scope

- Splitting any file. That is #173–#180 — and none of them can be honestly verified until this lands.
- Changing the 200-LoC threshold.

### Technical Context

The gate is `.github/actions/loc-gate/` (`action.yml`, `loc-gate.sh`, `generate-baseline.sh`), wired in `ci.yml`. The fix is a base-branch comparison; the data needed is already in git.

### Risks

⚠️ Until this lands, **every closed ticket in the #162 family that was verified by "loc-gate green" was verified by a check that cannot fail.** Worth re-checking the ones already closed.

### Test Plan

Per AC 4: open a PR that raises one entry, watch CI fail for the predicted reason; add the label, watch it pass; remove the raise, confirm green. State in the PR that you did.

### AI Usage Declaration

Found by Claude Opus 5 during the 2026-09-01 cross-repo triage sweep, while auditing acceptance criteria for stability. The baseline trajectory above was reconstructed by walking `git log` over `.github/loc-baseline.json` and reading the value at each commit — it is measured, not inferred. AI output is not truth; the owner verifies.