Handle private repo auto-merge fallback

[jmcte]

Summary

• Adds explicit GitHub plan-limit detection for private repos where auto-merge remains unavailable.
• Documents the fallback merge-readiness policy in generated bootstrap guidance and PR templates.
• Adds coverage for plan/apply fallback reporting and rendered guidance.

Governing Issue

Closes #12

Validation

• npm run check
• Required PR checks are expected to satisfy CI Gate
• Skipped checks are explained below

Bootstrap Governance

• Changes are scoped to the linked issue
• Contributor or PR guidance changes are reflected in CONTRIBUTING.md, .github/PULL_REQUEST_TEMPLATE.md, and docs/bootstrap/onboarding.md when applicable
• Auto-merge is enabled, or GitHub plan-limit evidence is recorded and the fallback merge-readiness policy applies
• No real secrets, runtime auth, or machine-local env files are committed

Merge Automation

• Auto-merge is unavailable for GitHub Free private repos; this change adds the fallback merge-readiness path for that plan-limited case.

Notes

• No skipped checks.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: defa3acf5a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Base fallback planning on desired repo visibility

planGitHub currently triggers the auto-merge-plan-limited action whenever the existing repo is private and reports allow_auto_merge: false, even if this run is about to change visibility to public. In that scenario (for example, moving a private repo to public on GitHub Free), auto-merge can be available after apply, so the plan incorrectly tells operators to use manual fallback merge readiness and can produce plan/apply mismatch.

Useful? React with 👍 / 👎.

[athena-omt]

I reviewed the current diff against issue #12. I do not have an additional independent blocker beyond the existing unresolved inline comment on src/github/provision.ts: the fallback planning signal is still based on the current repo visibility/allow_auto_merge state, so a private-to-public visibility change can incorrectly report the manual fallback path even though auto-merge should become available after apply. That should be resolved before treating this as merge-ready.

Validation note: I was not able to run local read-only checks because shell commands failed before execution in this environment with bwrap: Failed to make / slave: Permission denied; this review is based on the GitHub connector diff, issue context, and changed file contents.