feat: adopt shared-checkout-pr, and let the protection check read

[CartagoGit]

Two things Tanit was missing to close the migration on its side.

The config described a different model than the repository enforced

develop and main have been protected and requiring ci-summary for a while, but delendai.config.json carried no development block — so the resolved policy fell through the legacy compatibility layer to shared-direct.

It now selects shared-checkout-pr explicitly: ci-summary as the required check, 0 approvals on the integration branch and 1 on the release branch. Certified work integrates autonomously; promoting to a release keeps a human in the loop.

Resolved and validated against the policy engine before committing:

profile: shared-checkout-pr   integration: develop   release: main
checks: [ci-summary]   approvals: 0   releaseApprovals: 1
usesWipRefs: true      violations: 0

The protection check could not read the protection

branch-protection has failed on every run, and not because anything was wrong with the protection. It passed github.token, which cannot read branch protection at all — that needs Administration: read.

It now prefers BRANCH_PROTECTION_TOKEN, a fine-grained read-only token, falling back to the default. Deliberately not an admin token: a check that can rewrite the rules it verifies is not a check.

The script also conflated three outcomes, which is why the failure was unreadable:

• 404 on /protection reported required_status_checks.contexts ausente. It actually means the branch has no rule at all — the old wording sent a reader to fix a field inside a protection that does not exist.
• 401/403 was reported as "GitHub rechazó la protección", as though the protection were wrong, when nothing had been read. It stays a failure — a check that could not verify a property cannot certify it — but now names the cause and the remedy.

🤖 Generated with Claude Code