fix(grug): self-heal the ruleset grug actually found, not the one on file

[quadseven]

Why

detect_enforcement can classify a repo grug_managed through its name-prefix heuristic on a ruleset whose id is not the stored one - a rename or other drift leaves the stored id stale (grug#565). But ensure_enforcement's self-heal still targeted stored_ruleset_id.

When they diverge: get_ruleset(stale_id) 404s, the caller's broad except logs a warning, and that repo silently never heals. A self-heal that cannot report its own failure is worse than none - it reads as working.

Flagged by CodeRabbit on PR #685 and scoped out of it deliberately, because fixing it is a public-contract change.

Summary

• detect_enforcement now returns EnforcementDetection(state, ruleset_id) - the id of the ruleset that actually produced the classification.
• The self-heal uses that id, and persists the correction so the next pass starts from truth (same posture as heal_enforcement's post-recreate persist). The persist is best-effort: a store hiccup must not stop the heal it was recording.
• ruleset_id is None whenever no specific ruleset was matched (external via legacy branch protection, and every none), so the self-heal falls back to stored_ruleset_id and that path is unchanged.

Call sites: enforcement.py consumes the id; poller_handler.py and installations.py take .state.

Acceptance criteria

• detect_enforcement returns the matched live ruleset id, not just the state string - EnforcementDetection NamedTuple
• Self-heal uses the live-matched id when it differs from stored, and persists the correction
• All 3 call sites updated; the detect endpoint's HTTP response shape is unchanged (still just the state string)
• Regression test: detection finds a live Grug ruleset whose id differs from the persisted one, and migrate_check_context is asserted to target the LIVE id (999), not the stale stored one (555)
• Full webhook suite green: 1871 passed, 2 skipped, 0 failed. API suite: 288 passed.

Size

Size: M

Out of scope

• Any change to detect_enforcement's matching or classification LOGIC (prefix heuristic, id-match-first ordering). Only its return shape changed.

Note on the 40 updated test sites

Existing mocks now return ruleset_id=None on purpose: that reproduces the old fall-back-to-stored behaviour exactly, so every updated test keeps asserting what it always asserted rather than being re-baselined to the new code. The drift case gets three new tests of its own - heal targets the live id, no needless store write when it already matches, and a persist failure does not block the heal.

closes #686

[grug-tribe]

Grug walk most of trail. Some ground not walked.

fix(grug): self-heal the ruleset grug actually found, not the one on file

Grug Elder - Partial coverage - no markings on the ground Grug walked - check `neutral`

• Fast look only - deep look may add more.

---

Some ground not walked this pass - part of the diff did not fit one look. What Grug did walk is above. Grug not say trail safe for ground Grug not walk.

[quadseven]

Elder's high-complexity marking on github_rulesets_client.py:482 was correct and is now fixed in f8f9bfe.

Tracking WHICH ruleset matched (the point of #686) added two branches and pushed detect_enforcement to cyclomatic 16 against a cap of 15. Confirmed with radon rather than argued with:

before:  detect_enforcement          C (16)
after:   detect_enforcement          B (6)
         _match_enforcing_ruleset    C (11)

The scan loop moved to _match_enforcing_ruleset, which returns the classification plus the matching id, or None when no ruleset enforces the check so the caller still falls back to legacy branch protection. Behaviour is unchanged - 1871 webhook + 288 api tests pass with no test edits.

Noting for the record that this finding arrived only in the board comment, not as a review thread, so pr-bot-comments.sh reported clean. Worth reading the board even when the sweep exits 0.