[DNM] versi V3-activation test: YAP/glutton V3 scheduling + westend-100 epochs (stable2606)

[iulianbarbu]

Do not merge. CI-image vehicle for the versi V3 candidate-descriptor activation test — deployment PR: paritytech/parity-devnet#263. Based on the stable2606 tip.

What this provides in the versi stack

The test deploys a mixed stable-release network and flips node feature bit 4 (CandidateReceiptV3) live via sudo:

• validators: 18× parity/polkadot:stable2512 (legacy collator protocol, truly v2-only) vs 18× parity/polkadot:stable2606 with --experimental-collator-protocol (2 of them bootnodes) — the legacy-vs-revamp interop axis rides along. V3 acceptance itself is gated purely by the node feature (backing's v3_ever_seen latch on finalized blocks), not by the flag;
• para 2201: glutton-westend on released polkadot-parachain:v1.21.3 (stable2512 line), 3 cores;
• para 2202: glutton-westend on released polkadot-parachain:stable2606, 3 cores;
• para 2900: YAP with V3 scheduling enabled — the image built by this PR (paritypr/polkadot-parachain-debug), 3 cores. Idle until activation, then backed by the stable2606 cohort;
• relay genesis code: the westend-staging runtime embedded in this PR's paritypr/polkadot-debug image.

Changes

1. yet-another-parachain: enable V3 scheduling — accept-all VerifySchedulingSignature (V3_SCHEDULING_ENABLED = true), native relay-parent-offset 1 and velocity 12 untouched. No published runtime enables V3 (upstream it's a cargo feature of the cumulus test runtime only), hence this build.
2. glutton-westend: same V3 enablement (native RPO 1, velocity 3) — spare V3 runtime option on the same image.
3. westend: 100-slot fast-runtime epoch + proportional election phases — re-applies the westend hunks of [DNM] Hacks to obtain a rococo runtime with 10m session #8467 (westend-100) on stable2606, so the new versi genesis keeps the 10-minute sessions of the network it replaces (stock fast-runtime would give 2-minute sessions).

Upstream V3+offset coverage exists only on master and only at velocity 1 (scheduling_v3.rs), so YAP at RPO 1 / velocity 12 on a mixed 2512/2606 validator set is exactly the untested territory versi is meant to explore.

[cla-bot-2021]

User @claude, please sign the CLA here.

[github-actions]

This pull request is amending an existing release. Please proceed with extreme caution,
as to not impact downstream teams that rely on the stability of it. Some things to consider:

• Backports are only for 'patch' or 'minor' changes. No 'major' or other breaking change.
• Should be a legit fix for some bug, not adding tons of new features.
• Must either be already audited or not need an audit.

Emergency Bypass

If you really need to bypass this check: add validate: false to each crate
in the Prdoc where a breaking change is introduced. This will release a new major
version of that crate and all its reverse dependencies and basically break the release.