Add docs-first recovery reconciliation workflow

[kojiromike]

Summary

When the docs-first path is taken for a release (docs land before, or independently of, the tag in openemr/openemr), partial-merge or out-of-order conditions can leave install, upgrade, and release-notes pages rendered against a version that does not match the real tag once it lands. Today this is recovered manually: an operator re-runs the docs workflow with the correct tag inputs and inspects each affected page.

This issue proposes a dedicated reconciliation workflow that, given the real tag, re-renders the affected docs pages against it and brings the published site back into a consistent state without manual steps.

Why

• Manual recovery is error-prone and undocumented in a way that scales to new releasers.
• The docs-first path is now a supported flow, so its failure modes deserve first-class recovery tooling rather than a runbook.
• A scripted reconciliation is testable; a manual recovery is not.

Scope (proposed)

• Inputs: the authoritative openemr-tag (must exist in openemr/openemr) and the release line.
• Behavior: re-render install, upgrade, and release-notes pages against the real tag; diff against currently-published state; promote the corrected pages.
• Idempotent: safe to re-run.
• Logs what it changed so the operator can verify.

Notes

This was flagged as a future follow-on in the release process documentation and has not been filed until now.