governance: reconcile branch sync policy with no-merge-commit rule

[T72]

Summary

Current governance rules conflict with required release branch
synchronization:

• workflow/process expects regular main -> develop sync after
  releases
• branch protections/rules include: This branch must not
  contain merge commits

This combination prevents clean ancestry-based backmerge and
keeps origin/main...origin/develop persistently diverged (6 20
at time of issue).

Problem

• Classic backmerge PR from main to develop is blocked by no-
  merge-commit policy.
• Linear cherry-pick sync can carry patch-equivalent content,
  but branch history remains diverged.
• Housekeeping signals based on commit divergence become
  noisy/ambiguous.

Proposal

Define and enforce one explicit synchronization model:

1. Merge-commit sync model: allow merge commits for main ->
   develop sync PRs, OR
2. Linear sync model: keep no-merge-commit rule and formalize
   patch-equivalence sync + adjusted health metrics.

Acceptance Criteria

• Documented branch sync standard in governance docs/
  workflows.
• Protection rules align with the chosen standard.
• Backmerge/sync workflow no longer produces blocked/
  contradictory states.
• Housekeeping check uses the correct signal (ancestry parity
  vs patch parity) per chosen model.

Context

• Release v2.9.2 published successfully.
• Multiple sync PRs merged, but origin/main...origin/develop
  remains diverged due rule/strategy mismatch.