bug(gl-settings): kahuna-sandbox composite fails on existing any_approver rule + creates rule unscoped

[bakeb7j0]

Summary

gl-settings kahuna-sandbox <project-url> (the composite operation from gl-settings#27) fails with HTTP 400 on POST when the project already has a pre-existing any_approver rule. Additionally, when it does succeed, the created kahuna-zero-approvals approval rule is unscoped — but /precheck skill body's "Sandbox Auto-Approval" section explicitly contracts the rule MUST be scoped via protected_branch_ids to the kahuna/* pattern (see CLAUDE.md and skills/precheck/SKILL.md).

Severity: medium — kahuna sandbox setup fails on real-world projects, AND when it does succeed the security model is wrong.

Origin: Reported by sibling-campaign agent. @Scryer to expand on the exact 400 response shape, the project where this was observed, and the recommended fix (probably: detect existing any_approver rule and replace/upgrade rather than POST a new one; always pass protected_branch_ids matching the kahuna/* pattern).

Implementation Steps

TBD — @Scryer to expand.

Test Procedures

TBD — should include a test against a project that already carries a default any_approver rule (most non-empty GitLab projects do).

Acceptance Criteria

• gl-settings kahuna-sandbox composite handles pre-existing any_approver rule without 400
• Created kahuna-zero-approvals rule is scoped to kahuna/* pattern via protected_branch_ids
• Skill body's contract honored: rule MUST NOT be project-wide

Dependencies

• gl-settings#27 (composite operation source)

Metadata

Severity: severity::major (operational blocker for kahuna setup on existing projects)
Origin: sibling-campaign tracker, deduped against existing cc-workflow issues 2026-05-07. @Scryer owns expansion.