[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

`generate-baseline.sh:8` states the rule plainly: regenerate after a real split, *"never to paper over a file that grew."* Nothing enforces it.

A green check that certifies the opposite of what it claims is worse than no check. Epic #506's burn-down is measured against baselines that move with the code, so its children cannot be honestly verified.

### Current Behavior

Verified on `origin/main`. The four files named by #519/#520/#521 are grandfathered at their **current, grown** sizes:

| File | Baseline entry | Size the burn-down ticket argues from |
|---|---|---|
| `crates/lightbridge-authz-rest/src/lib.rs` | **4528** | 4,068 (#519) |
| `app/lightbridge-authz/src/mcp.rs` | **3575** | 3,274 (#520) |
| `crates/lightbridge-authz-api-key/src/repo.rs` | **3421** | 2,950 (#521) |
| `crates/lightbridge-authz-core/src/config/mod.rs` | **2173** | 2,010 (#521) |

The baseline was refreshed upward in `0e7308a` ("Merge main into feat/loc-gate-ci and **refresh LoC baseline**"). So #519's stated goal — "reduce from the 4,068-line baseline" — is measured against a number that no longer exists, and its verification box "every new or changed `src` file is ≤ 200 LoC" passes today with `lib.rs` untouched at 4,528, because the gate grandfathers it.

⚠️ **The same defect exists in `lightbridge-governance`**, the repo this gate was ported FROM (`c42079c`). There, `otel.rs` walked 1522 → 1580 → 1671 → **1837** across four commits, one titled *"chore(loc-gate): raise the baseline"*. Fix both, or the next 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 legitimate raises 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**; with the label, passes. Write it to fail first.
5. #519/#520/#521's acceptance criteria are re-stated against the baseline file rather than a remembered number: *"`` no longer appears as a key in `.github/loc-baseline.json`, proven by the diff in the same PR."*

### Out of Scope

- Splitting any file — that is #519/#520/#521, none of which can be honestly verified until this lands.
- Changing the 200-LoC threshold. (#516, which added the gate, is closed and correct as far as it went.)

### Technical Context

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

### Risks

⚠️ Epic #506 currently reports progress against a moving floor. Until this lands, "loc-gate green" is not evidence for any burn-down claim.

### Test Plan

Per AC 4: open a PR raising 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. Every number above was measured on `origin/main` (`git show origin/main: | wc -l` and the committed baseline), not taken from the tickets — which is how the discrepancy surfaced. AI output is not truth; the owner verifies.