enable_pr_auto_merge is unusable on this repo — every merged-pr task falls back to manual merge

[missingbulb]

Both merged-pr-ceiling tasks that ran a merge today failed to arm auto-merge, for what look like two different surfaced reasons, and both subagents fell back to a manual merge_pull_request call once required checks were green (self-reported deviation in both cases; verified independently — see issues #428 and #425's convergence comments for evidence checked against pull_request_read/check-run state).

• growth-extract (PR Claudinite growth: extract lessons #436): enable_pr_auto_merge refused while test-and-conformance was still in_progress ("unstable status"), then refused again once it went green: "already in clean status (all checks passed) — auto-merge only applies when checks are pending."
• conversation-extract (PR Claudinite growth: conversation extract #438, via a concurrently-dispatched run — see Executor claim step raced: dispatch issue #427 ran twice #452): enable_pr_auto_merge first returned "required checks are failing" while the check was in_progress, then once green returned "Protected branch rules not configured for this branch."

The second message suggests the root cause: GitHub's auto-merge feature requires the repo to have a branch protection rule (or the "Allow auto-merge" repository setting) configured on the target branch, and this repo apparently doesn't have one. If so, enable_pr_auto_merge will never succeed here regardless of check timing — every merged-pr-ceiling task (growth-extract, growth-discover-packs, conversation-extract) will keep hitting this and improvising a manual-merge fallback, which:

1. Isn't what the task docs literally instruct ("arm auto-merge... never manually force-merge yourself" was the executor's own dispatch instruction today, since the docs assume auto-merge works);
2. Works today only because each subagent independently chose to wait for green CI before merging — a good instinct, but it's ad hoc judgment standing in for a structural guarantee, and a future run (or model) could get that judgment wrong;
3. Trips the harness's generic "self-authored PR merged without review evidence" security flag on every single run, which is noisy and will desensitize whoever reviews these flags.

Suggested fix (for owner/engineering, not doing this myself — outside an executor session's write surface): enable "Allow auto-merge" in repo settings (Settings → General → Pull Requests) and/or configure a branch protection rule on main that auto-merge can attach to. Once that's in place, re-verify a merged-pr task can actually arm auto-merge end-to-end rather than needing the manual-merge workaround.