Route GitHub infrastructure changes through review

[davejohnson]

Summary

• add github.collaboration.pullRequests.manageTemplate so repositories can require pull requests while keeping their existing template unmanaged
• preserve the template file when Hypervibe releases prior ownership instead of treating it as a retired file to delete
• route generated environment deployment workflow changes through the deterministic hypervibe/github-infrastructure branch and pull request
• defer workflow secrets, local bindings, and the applied-spec marker until the reviewed workflow is present on the default branch

Why

Hypervibe v0.1.3 unconditionally generated .github/PULL_REQUEST_TEMPLATE.md whenever requirePr was enabled. Its environment deployment workflow apply path also wrote workflow files directly to the repository default branch and immediately synced secrets. Those behaviors prevented repositories from enforcing review for every infrastructure file change.

User impact

Projects can set manageTemplate: false to preserve repository-owned pull-request templates. Applying deployment workflow drift now returns an honest pending receipt with the infrastructure PR URL; after a person merges it, a fresh plan/apply syncs the deferred secrets and bindings.

Verification

• npm run typecheck
• npm test -- --configLoader runner — 104 files and 813 tests passed
• npm run build
• npm_config_cache=/private/tmp/hypervibe-npm-cache npm run prepublish-check
• git diff --check

Existing expectations changed

The core deploy-workflow apply expectation now requires a pending infrastructure pull request rather than a successful direct repository write. New coverage proves secrets and bindings remain untouched before merge, are synchronized after the reviewed file appears on the default branch, and repository-owned templates are not deleted when ownership is released.

Risks / follow-up

• Deployment workflow reconciliation now requires a human merge followed by a fresh plan/apply cycle.
• manageTemplate defaults to true, preserving compatibility for existing desired-state specs.
• After merge, publish a new Hypervibe patch release before using the new field from downstream repositories.