docs(governance): add roadmap merge gate to contributing and PR template

[parthrohit22]

Summary

Makes the roadmap-alignment rule structural instead of advisory. PARTHA's direction is set by the roadmap (PARTHA_Market_Fit_Product_&_Engineering_Roadmap.html) as the single source of truth. Until now that was a local AGENTS.md note a contributor could ignore. This change puts the gate where contributors cannot avoid it: CONTRIBUTING.md and the pull request template.

Linked issue

Related to #115 (governance/operations hardening workstream). This is a process gate, not a feature issue.

Roadmap alignment

• Roadmap §23 workstream this advances: §12/§13 governance & operations — the discipline that keeps work on the critical path toward §28 market-fit criteria.
• §28 market-fit criterion this moves toward: indirectly supports all §28 criteria by preventing out-of-scope "quick useful surface" PRs from diluting focus.
• Accepted evidence it is real (test/usage/repo state, not intent): the existing self-merge incident (feat(intelligence): retire legacy mutable read model #181) and the breadth-drift risk identified during the roadmap review; this PR converts the local AGENTS.md rule into an enforced contributor-facing gate.

What changed

• CONTRIBUTING.md: new §0 "Strategy alignment (merge gate)" — names the roadmap as single source of truth, states the in-scope rule, and says a PR that cannot fill Roadmap alignment is out of scope.
• .github/pull_request_template.md: new mandatory "Roadmap alignment" section (§23 workstream, §28 criterion, accepted evidence) + a checklist item asserting it.

Acceptance criteria completed

• CONTRIBUTING.md documents the merge gate and points to the template section.
• PR template requires Roadmap alignment on every PR.
• Language consistent with the existing AGENTS.md/CLAUDE.md source-of-truth section.

Testing performed

Documentation-only change; no build/test impact. Verified with git status that only the two governance files are staged (.hermes/ left untracked).

Screenshots

Not applicable (docs only).

Security and data considerations

None — documentation only. No auth, owner-scoping, secrets, logging, or migration changes.

Dependencies and blocked work

None.

Scope changes or remaining work

One known gap surfaced while building this: the roadmap is a local (gitignored) file contributors in a fork cannot see, so they cannot fill the §28 field without asking the maintainer. This PR documents that ("ask the maintainer if you cannot see it") rather than silently papering over it. A follow-up could publish a contributor-visible summary of §23/§28, but that is a deliberate owner decision and out of scope here.

Contributor checklist

• This PR targets dev
• The branch was created from an up-to-date upstream/dev
• The branch is rebased on the latest upstream/dev
• This PR addresses one clearly scoped issue
• This PR advances a §23 workstream toward a §28 market-fit criterion (Roadmap alignment filled)
• Documentation is updated for any user-visible change
• No secrets, credentials, local env files, or generated artifacts are included
• No unrelated files were changed
• Dependencies and follow-up work are linked