Release workflow cannot be re-driven when GitHub drops the triggering event

## Summary

`.github/workflows/create-release.yml` triggers only on `pull_request: types: [closed]`. When GitHub drops or never records that event, the release cannot be re-driven: a merged PR cannot be reopened, and the workflow has no `workflow_dispatch`.

This happened today with 3.1.3. PR #1101 merged cleanly at 16:11 UTC during a GitHub Actions degradation ("We are investigating reports of degraded availability for Actions"). No run record was created for the merge at all — unlike other runs from the same period, which exist and sit in `queued`, so there is nothing to drain when Actions recovers.

Result: `trunk` carries the 3.1.3 version bump at `a4f8616`, and there is no `3.1.3` tag, no GitHub release, and nothing pushed to WordPress.org. The release has to be finished by hand with `node scripts/create-release.mjs 1101` plus a separate SVN deploy.

The state is benign — a release that never started rather than one that half-finished — but the recovery path should not be "run the release script off a laptop".

## Suggested change

Add `workflow_dispatch` alongside the existing trigger, taking the release PR number as an input:

```yaml
on:
pull_request:
types: [closed]
branches: ['trunk']
workflow_dispatch:
inputs:
pr_number:
description: 'Release PR number (e.g. 1101)'
required: true
```

Three things need adjusting for that to work, because the job currently reads the event payload directly:

- The `if` at line 12 (`github.event.pull_request.merged == true && startsWith( github.head_ref, 'release/' ) && …`) is false for a manual dispatch, so it needs a branch for `github.event_name == 'workflow_dispatch'`.
- `github.event.number` is used at lines 31, 49 and 63. Those want a single resolved value, e.g. a step output or `${{ github.event.number || inputs.pr_number }}`.
- `scripts/create-release.mjs` already takes the PR number as `process.argv[2]` (line 46), so the script itself needs no change.

Worth deciding as part of this: whether a manual dispatch should re-verify that the PR was actually merged and that its head branch started with `release/`, rather than trusting the operator. The guard exists to stop a non-release PR triggering a deploy, and a hand-typed number bypasses it.

## Related

`scripts/create-release.mjs` is idempotent for a release that already completed — there is a comment at line 52 about skipping the changelog/tag/GitHub steps on a prior run. Worth confirming that holds before relying on re-dispatch, since the whole point is running it a second time.

Suggested labels: `enhancement`, `ready-for-agent`.

Start with .github/workflows/create-release.yml, especially the trigger, the guard at line 12, and event-number uses at lines 31, 49, and 63. Then inspect scripts/create-release.mjs around lines 46 and 52 to confirm its PR argument and idempotence. Done means a manual dispatch can safely re-drive a merged release PR and preserves the release-only guard.

Written by the indexing model from the issue text.