ci: база стабильного кандидата — предыдущий стабильный тег (#587)

Относительная половина «Полных бенчмарков» сравнивала кандидата с прошлой
вершиной `main`. Для стабильного релиза это давало круг, в котором гейт не
может покраснеть дважды: прогон идёт только на push в `main`, кандидат обязан
там оказаться, и следующий коммит той же линейки берёт базой первый — то есть
линейку саму. На выпуске v1.76.0 это видно построчно: прогон 35097102695 на
`c3d64789` честно показал resizePreview 603 → 981 и panZoom 91 → 205 в скрытой
изометрии, а прогон на `9683a590` был зелёным и был бы зелёным без всякой
правки бюджетов.

Теперь база выбирается по намерению коммита: head несёт трейлер `Release:` без
пре-релизного суффикса — сравниваем с предыдущим стабильным тегом. Бета,
обычный push и ручной `comparison_ref` не меняются.

Решение вынесено из shell в `scripts/performance-baseline.mjs` по тому же
доводу, что и разбор вердикта ревью (#556): отрицательные случаи — тега нет,
тег стоит на самой голове, база перестала быть предком, база старше
HP-PERF-01 — в YAML не прогнать ни одним тестом. Обращения к git инжектируются,
фикстуры описывают дерево. Отказы по-прежнему уводят в сторону БОЛЬШЕГО
сравнения: непригодная база → родитель → последний достижимый релизный тег.

Проверено исполнением на этом репозитории: стабильный кандидат v1.76.0 →
`2c6410bb` (v1.75.0); бета v1.76.0-beta.5 и обычный push → `push before`;
dispatch с `comparison_ref=v1.74.0` → `e63460f0`.

Свидетели: `test/performance-baseline.test.mjs` (10 проверок, включая AC2 —
второй коммит линейки не сравнивается сам с собой) и мутант
`stable-candidate-compares-against-itself`, который возвращает прежнее
поведение и обязан краснеть; проверено подменой руками — AC2 падает, оригинал
проходит.

AC4: других релизных гейтов, судящих о родителя, нет. `validate.yml` берёт
`github.event.before` только для ДИАПАЗОНА файлов, и там база уже заменена
доказанно зелёным предком (#387/#388), а не сырым родителем.

npm test 2731/2730/0 fail, typecheck чистый, check-docs зелёный (кроме
известного отпечатка скриншотов, #586).

Issue: #587
User-Visible: no

demo/performance/README.md

@@ -109,6 +109,21 @@ applies two limits:
 1. a relative regression allowance against the base-SHA report;
 2. an absolute safety ceiling from `budgets.json`.
 
+Which base SHA the relative half compares against is decided by
+`scripts/performance-baseline.mjs`, not by the workflow's shell (#587). A
+**stable** release candidate — its head commit carries a `Release:` trailer
+without a prerelease suffix — is compared against the **previous stable tag**;
+everything else keeps the old base (`push before`, the candidate parent, or the
+`comparison_ref` a manual dispatch names). The reason is the order the stable
+gate imposes: the candidate must be on `main` before this workflow can run on
+its exact SHA, so the *next* commit of the same line would otherwise take the
+first one as its base and compare the line with itself — a red gate would be
+cleared by any follow-up commit. The negative cases of that decision (no tag,
+a tag sitting on HEAD, a base that is no longer an ancestor) cannot be exercised
+from YAML, so they live in `test/performance-baseline.test.mjs` with an injected
+git; the mutant `stable-candidate-compares-against-itself` puts the old
+behaviour back and must be caught.
+
 The tighter limit wins. The absolute values are catastrophic safety ceilings,
 not normal-performance targets; the base-relative comparison catches smaller
 regressions. Small fast operations receive an absolute noise