[eble-amd]

Purpose

Merge 955bd6a from upstream to gfx11 in stages dictated by conflicts. Notes on conflicts:

1. from 7d99c2c
   Resolved insert-insert conflict in csrc/libtorch_stable/moe/moe_permute_unpermute_op.cu by keeping both sides.
2. from 0b7f11a
   File conflicts were resolved automatically by meld.
3. after e9f169d
   Inserted a newly minted commit to disable the pre-commit check named check-test-tethering because we are not testing the gfx11 branch with Buildkite, so it does not make sense to force ourselves to maintain related scripts.
4. from a33b3ba
   Resolve insert-insert conflicts in qwen2_5_vl.py by keeping both sides. They involved build_qwen2_5_vision_transformer and Qwen2_5_VLDummyInputsBuilder.
5. from 2af0551
   Resolved insert-insert conflicts in envs.py by keeping both sides.

Validation (agentic)

Radeon 8060S (gfx1151), ROCm 10.2.0a20261019, torch 2.13.0, Triton 3.8.0.
Base 38e70e9c008c, PR 68e21e98d19d. Serving benchmarks, one request at a time.

Case	TTFT ms base	TTFT ms PR	TTFT Δ	TPOT ms base	TPOT ms PR	TPOT Δ
Qwen3.6-35B-A3B-W4A16 VLM, MTP, MMStar	200.6	198.3	-1.1%	10.15	10.09	-0.6%
Qwen3.6-35B-A3B-W4A16 VLM, 4k prefix + 1k, prefix caching	451.9	451.2	-0.1%	12.24	12.19	-0.4%
Qwen3-30B-A3B-Instruct-2507-AWQ, EAGLE3, AIME	226.2	221.4	-2.1%	13.98	13.98	-0.1%
Gemma-4-E4B-IT-AWQ VLM, DFlare, RoboVQA	314.7	307.5	-2.3%	6.00	5.97	-0.5%
Gemma-4-31B-IT-AWQ VLM, ?, MTP, MMStar	1237.0	1223.1	-1.1%	36.07	36.06	-0.0%
Qwen3-VL-4B-Instruct-AWQ VLM	679.4	672.1	-1.1%	14.16	14.17	+0.1%

All cases pass on both builds with identical input and output token counts.
Speculative acceptance length is unchanged except Qwen3.6 MTP (1.846 base, 1.842 PR).
Differences are within run-to-run variation (about 2%).

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.
• (Optional) Release notes update. If your change is user facing, please update the release notes draft in the Google Doc.