Fix wiki workflow branch-protection publishing flow

[coisa]

Problem

The wiki update workflow currently conflicts with protected main branch rules because it expects the generated wiki submodule reference to be committed directly after merge. That was the previous flow, but branch protection now prevents the workflow from updating the parent repository pointer on main in that shape.

Current Behavior

The packaged consumer workflow in resources/github-actions/wiki.yml only calls the reusable wiki workflow for pushes to main. This does not exercise the new PR preview flow and keeps consumers aligned with the branch-protection-sensitive publishing model.

Expected Behavior

When a pull request is opened, updated, reopened, or receives new pushes, the wiki workflow should generate Markdown docs into a PR-scoped wiki branch and commit the resulting .github/wiki submodule pointer back to the PR branch. When that pull request is merged into main, the workflow should publish the content from the PR wiki branch into the wiki main branch.

Failure Surface

• .github/workflows/wiki.yml
• resources/github-actions/wiki.yml
• .github/wiki submodule pointer updates generated by wiki preview runs
• Consumer repositories that install the packaged workflow stub with composer dev-tools:sync

Proposal

Adopt the new two-stage wiki workflow as the natural development flow and update the packaged consumer stub so it invokes the reusable workflow on pull request preview events and merged pull request publish events.

Implementation Strategy

Keep the reusable workflow logic in .github/workflows/wiki.yml and update resources/github-actions/wiki.yml to call it for:

• pull_request events with opened, synchronize, and reopened activity types;
• pull_request_target closed events, guarded by the reusable workflow so only merged pull requests targeting main publish to the wiki main branch;
• workflow_dispatch for manual testing.

Preserve write permissions required for committing the wiki branch and parent repository submodule pointer while avoiding direct post-merge commits to protected main.

Non-goals

• Redesigning the wiki generator command or generated Markdown content.
• Changing branch protection settings.
• Replacing the .github/wiki submodule model.
• Updating unrelated workflow stubs.

Acceptance Criteria

Functional Criteria

• Pull request wiki updates generate and push content to a PR-scoped wiki branch named from the pull request number.
• Pull request wiki updates commit the .github/wiki submodule pointer to the pull request branch when the generated wiki content changes.
• Merging a pull request into main publishes the PR wiki branch content to the wiki main branch.
• Closing a pull request without merge, or merging into a branch other than main, does not publish to the wiki main branch.
• resources/github-actions/wiki.yml calls the reusable workflow for the same PR preview and merged-PR publish events needed by consumer repositories.

Regression Criteria

• The workflow remains manually runnable through workflow_dispatch for experimental validation.
• The workflow keeps the minimum permissions needed for contents updates and pull request reads.
• Existing generated wiki content is not regenerated or reformatted outside the expected submodule pointer update.

Architectural / Isolation Criteria

• The change stays scoped to the wiki workflow and packaged workflow stub.
• Consumer sync behavior continues to copy a small workflow stub from resources/github-actions instead of duplicating the reusable workflow implementation.
• The implementation remains deterministic for repeated pushes to the same pull request branch.

[coisa]

Reopening after PR #49 exposed a publish failure: the wiki repository uses as its publish branch, but the workflow tried to fetch and push . A follow-up PR will correct the wiki publish branch.

[coisa]

Follow-up correction: PR #49 exposed a publish failure because the wiki repository uses master as its publish branch, while the workflow tried to fetch and push main. The next PR will update the publish job to target the wiki master branch.

[coisa]

Reopening again after checking the publish logs: EndBug/add-and-commit did not push the wiki publish branch when the reset produced a clean working tree. A follow-up PR will replace that publish step with an explicit protected push before deleting the preview branch.