Deploy fails on fork repo

Summary

The automatic documentation preview deploy (documentation-deploy.yml)
fails for PRs opened from forks. The Resolve PR number step can't
determine which PR the build artifacts belong to, so the job errors out
and no preview gets deployed or linked back on the PR.

Steps to reproduce

1. Open a PR from a fork against main.

2. Wait for the Documentation workflow to complete successfully

   (it uploads documentation and a11y-coverage artifacts on the
   pull_request event).

3. Watch for Documentation deploy to fire via workflow_run.

Expected behavior

documentation-deploy.yml downloads the artifacts, deploys them to
Surge, and posts a preview link back on the PR automatically.

Actual behavior

The job fails at the Resolve PR number step. Reproduced twice on the
same fork PR (#12653), failing identically on both the "opened" and
"synchronize" triggers:

• Run #100 (opened): https://github.com/patternfly/patternfly-react/actions/runs/34976649550

• Run #101 (synchronize): https://github.com/patternfly/patternfly-react/actions/runs/34978910732

Both fail within ~1 minute, at the same step, with the same downstream
failure in Upload accessibility results (which still attempts to run
via if: !cancelled(), then fails because the coverage artifact was
never downloaded).

Root cause

Resolve PR number first checks github.event.workflow_run.pull_requests,
which GitHub leaves empty for any fork PR by design (it's only
populated when the PR's head branch is in the same repo as the base).
That sends every fork PR into the fallback path:

PR_JSON=$(gh api --paginate "repos/${REPOSITORY}/commits/${HEAD_SHA}/pulls")

That API call is coming back with something other than exactly one
match, which the script treats as unrecoverable and exits 1 rather than
guessing.

Suggested fix

Have documentation.yml save github.event.pull_request.number as its
own small artifact (same as it already does for documentation and
a11y-coverage) on the pull_request event, and have
documentation-deploy.yml download and read that artifact instead of
trying to resolve the PR number after the fact via the API. This removes
the lookup — and its failure mode — entirely, since the PR number would
travel with the run the same reliable way the other artifacts already do.

Workaround in the meantime

A frequent-flyers team member can comment /deploy-preview (exact
string, top-level comment on the Conversation tab) on the PR. This
routes through documentation.yml's issue_comment path, which deploys
directly and doesn't depend on the broken resolution step.

Jira Issue: PF-4647