Record branch protection as enabled on main

[June74]

What changed and why

Branch protection was enabled on main on 2026-08-17 with the six required checks, strict mode, and administrator enforcement. .github/branch-protection.md still described enablement as pending owner approval, which is no longer true, and its ruleset heading still described a future action.

Requirements and decisions satisfied

• D-091 — "document the branch-protection ruleset in Stage 0 Wave A but enable it in Wave C" is now discharged. Wave A wrote the ruleset; Wave C built the checks; this records the enablement.
• Closes the last outstanding Wave C completion criterion.

Security and privacy effects

This changes enforcement, in the direction of more of it. CONTRIBUTING.md's published rule that direct implementation commits to main are not allowed is now enforced by GitHub rather than by policy alone.

Verified adversarially rather than by reading configuration back: a direct push to main using the owner's own credentials was rejected by the server with "Changes must be made through a pull request" and "6 of 6 required status checks are expected". enforce_admins: true therefore binds the maintainer, which is the point.

Verification

• gh api repos/June74/openmemory/branches/main/protection reports all six contexts, strict: true, enforce_admins: true, force-pushes and deletions disabled, zero required approving reviews.
• Direct push to main rejected; main unchanged.
• bash tools/check-links.sh — 68 links, 0 broken.
• This pull request is itself the first exercise of the ruleset. Wave C's own PR (Stage 0 Wave C: continuous integration #4) merged before protection existed, so the rules were never tested against the change that created them.

Remaining limitations or deferred work

• Required approving reviews are zero because a sole maintainer cannot approve their own pull request. GitHub enforces that checks pass and that changes arrive by pull request; it does not assess correctness. Independent codex exec review recorded in pull-request evidence is what stands in for a human reviewer.
• strict: true means every pull request must be up to date with main before merging, so a branch that falls behind must be updated and have all six checks re-run.

---

• Every commit is signed off (git commit -s), per the Developer Certificate of Origin.
• This change contains no secret value, credential, private transcript, or personal memory content.
• Planned behavior is not described as though it were implemented.