guardrails: enablement probe ignores local-only plugin scope (settings.local.json without project key)

[kyle-sexton]

Parent

Refs #912 (audit umbrella; finding F2 residual). Follow-up to #916 / PR #928.

What to build

source_control_enabled() in guardrails' flag-commit-pr-skill-bypass.sh resolves plugin enablement across user-global → project → local settings, but counts a settings.local.json value only when the project settings.json already declares the same key. Per the official settings scopes (https://code.claude.com/docs/en/settings — precedence Local > Project > User; claude plugin install --scope local is a first-class scope), a plugin enabled ONLY at local scope is active, yet the probe reads it as disabled and the gh pr create advisory never fires (silent false-negative, same class as #916).

Make a local-scope value participate in per-key resolution unconditionally: effective = local when present, else project when present, else user-global. Keep the existing per-exact-key iteration and uncertain→silent posture.

Acceptance criteria

• Enablement declared only in <repo>/.claude/settings.local.json resolves as enabled (advisory fires)
• Local false overrides project/user true; local true overrides project false
• Existing scope-resolution tests still pass; new red-first test covers the local-only case
• Header comment's scope description matches the implemented precedence
• Guardrails version bump + CHANGELOG entry (may batch with sibling guardrails fixes in one wave)

Blocked by

None — can start immediately

[kyle-sexton]