ci(perf): keep review edits on the tightening PR, pin actions

Address review: the ratchet no longer replaces an open tightening PR's
branch that carries commits it did not make, and pushes with explicit
leases on the tip it checked. The PAT-bearing job pins its actions to
commit SHAs. The docs say dispatch needs the file on master first.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/architecture/performance-journeys.md

@@ -585,11 +585,18 @@ When the file changed and the run is on `master`, the job pushes
 `automation/performance-ratchet` and opens (or updates) a pull request with
 the per-run table, the diff and the run URL, labelled `no-release-note`. It
 pushes with the existing `PAT` secret, as the Windows MPV pin refresh does,
-because a pull request pushed with `GITHUB_TOKEN` starts no CI. When no
+because a pull request pushed with `GITHUB_TOKEN` starts no CI. Each run
+replaces the branch with one fresh commit, except when the open tightening
+pull request carries a commit the workflow did not make (a review edit, an
+"Update branch" merge): then it leaves the branch alone with a warning, and
+the numbers stay in the job summary. When no
 baseline was below its value in all three runs, the workflow ends without a
 pull request. A dispatch on another branch measures and prints the diff but
-never opens one; use `gh workflow run performance-ratchet.yml --ref <branch>`
-to validate a change to the workflow. Review the pull request like a manual
+never opens one, so `gh workflow run performance-ratchet.yml --ref <branch>`
+validates a change to the workflow once the file is on `master`. GitHub only
+dispatches workflows that exist on the default branch, so before the first
+merge of a new or renamed workflow add a temporary `push` trigger for the
+branch and drop it before review, as #1760 did. Review the pull request like a manual
 tightening: if `master` moved since the measured commit, the
 `Initial bytes ratchet` job on the pull request is what shows that the new
 value still holds (the concurrent-merge effect above).

docs/architecture/validation-map.md

@@ -263,7 +263,9 @@ target `master` and for `master` pushes (dispatch it with
 `gh workflow run ci.yml --ref <branch>` for a stacked branch). The weekly
 `performance-ratchet.yml` workflow lowers baselines through a bot PR; validate
 a change to it with `gh workflow run performance-ratchet.yml --ref <branch>`,
-which measures but opens no PR off `master`. `perf:journeys` builds the `electron-performance` configuration and runs every
+which measures but opens no PR off `master`. Dispatch needs the workflow file
+on `master`; before that, see the temporary-trigger note under Weekly
+tightening in the performance journeys document. `perf:journeys` builds the `electron-performance` configuration and runs every
 journey spec against the Xtream mock: J1 launch, then J2 open-source (a
 second set of launches, each followed by the click on the portal card), both
 written to the same summary file; its probe specs run with