Make GitHub capability ownership opinionated

[davejohnson]

Summary

• remove the unreleased manageTemplate opt-out and its preservePaths transition machinery
• make requirePr exclusively own a stronger canonical .github/pull_request_template.md
• migrate the previously managed uppercase template path through manifest cleanup
• batch canonical GitHub files, the manifest, and generated environment deployment workflow drift into one reviewable infrastructure pull request
• reuse the canonical template for legacy collaboration compatibility and document capability-level ownership

Why

The temporary split-ownership design added configuration and reconciliation paths that worked against Hypervibe's desired-state model. Enabled GitHub capabilities should have one clear owner: Hypervibe. This keeps the surface smaller and makes drift behavior predictable while retaining externalWorkflows as the explicit read-only integration boundary.

Impact

Repositories that enable github.collaboration.pullRequests.requirePr receive the Hypervibe-owned canonical template. On the next infrastructure apply, a previously managed uppercase template is replaced with the lowercase canonical path. When deployment workflow drift occurs in the canonical GitHub environment, all known managed repository files are proposed in the same pending PR; secrets, bindings, settings, and the applied contract marker remain deferred until merge.

This removes only behavior introduced in the unreleased follow-up to #24, so no published compatibility period is required.

Verification

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

Risks and follow-up

After merge, release Hypervibe 0.1.4, rebuild/restart the MCP, then update the HLS desired state (enforceAdmins: true) and run the staged plan/apply workflow.