Rebuild release wiki publication from the main pointer

[coisa]

Summary

Release-time wiki publication should rebuild from the .github/wiki gitlink already recorded on main, and only republish the wiki branch when that rebuilt state produces content changes.

Why this matters

The release workflow checks out main with submodules, so the checked-in .github/wiki pointer is the repository source of truth for the release. Resetting the submodule to the current remote wiki branch before rendering makes the remote branch authoritative instead, which can:

• bypass the pointer currently recorded on main
• turn remote drift into unexpected pointer churn
• confuse merged-release summaries by talking about master instead of the main source branch

The earlier pr-308 failure was a symptom around release-time wiki automation being anchored to the wrong source of truth.

Expected behavior

• release wiki refresh starts from the .github/wiki pointer already checked out from main
• it cleans that working tree, rebuilds docs, and only publishes when the rebuilt content changes
• when it does publish, it updates the wiki branch and then reconciles the parent repo pointer
• merged-release summaries describe main as the source branch

Acceptance criteria

• refresh-release-pointer no longer resets to the current remote wiki branch before rendering
• release refresh keeps remote wiki drift non-authoritative when rebuilt content is unchanged
• release refresh can still republish successfully when rebuilt content changed, even if the remote wiki branch moved ahead
• merged-release wiki maintenance summaries refer to main as the source branch
• regression coverage is added for the release-pointer behavior