Keep release wiki pointer reconciliation compatible with branch protection

[coisa]

Summary

Release-time wiki publication still assumes it can reconcile the parent .github/wiki pointer by committing directly to main, but this repository is protected and requires changes to land through a pull request.

Problem

The release publication flow currently rebuilds and publishes the wiki from the merged release state, then tries to update the superproject gitlink in main from inside automation.

That is not compatible with the repository rules here:

• main is protected
• release updates must enter through a pull request path
• the workflow must not depend on a direct bot push to main

Why this is a bug

Even if wiki publication itself succeeds, pointer reconciliation can still fail or become non-compliant because the workflow is attempting the last step on the wrong branch boundary.

The release process should preserve these invariants:

• the wiki content may be rebuilt from the checked-in .github/wiki pointer on main
• any resulting pointer update in the parent repository must be proposed through a PR-safe path
• release automation must remain compatible with branch protection without requiring bypass permissions

Expected behavior

• release-time wiki publication should never require a direct commit to main
• if the rebuilt wiki changes the gitlink, the reconciliation should happen through a pull request-compatible path
• summaries and workflow behavior should reflect that the source of truth is the checked-in pointer from main, while the repo update itself still respects branch protection

Acceptance criteria

• no release workflow step depends on pushing a parent-repo commit directly to main
• wiki pointer reconciliation is routed through a PR-safe mechanism
• the release path remains automated enough to keep wiki publication and parent pointer updates consistent
• regression coverage or workflow assertions are added where practical