VT_QWEN35_STAGE_RESERVE_BYTES undocumented — the third env var to red main in two days, and the checker cannot see duplicates

Read the environment-variable handling at src/vllm/model_executor/models/qwen3_5_weights.cpp:213 and the two sibling entries in docs/ENVIRONMENT.md. Add VT_QWEN35_STAGE_RESERVE_BYTES beside that family, then run check-env-doc on a clean checkout to confirm the preflight is green.

VT_QWEN35_STAGE_RESERVE_BYTES is read from src/ and documented nowhere, so check-env-doc is RED on origin/main — the THIRD undocumented production env var to reach main in two days.

Read at src/vllm/model_executor/models/qwen3_5_weights.cpp:213, from the PERF-QWEN35-STAGE-WEIGHTS work. Reproduced on a clean checkout of origin/main at af9171a8e:

ERROR: production env var(s) read from src/+include/ are neither documented in
docs/ENVIRONMENT.md nor on scripts/env-doc-allowlist.txt:
  - VT_QWEN35_STAGE_RESERVE_BYTES

Every branch cut from main inherits a red preflight until it is fixed.

FIXED IN FLOW, documented in docs/ENVIRONMENT.md beside its two siblings, where that family already lives.

The pattern is the actual issue

This is the third in two days, all in the same shape — a knob lands in src/, nobody documents it, main goes red, and the next person to run preflight pays for it:

Two things follow, and neither is fixed here because both are CI-ownership questions rather than this row's:

1. check-env-doc is evidently not blocking merges. If it ran as a required check, none of these three could have landed.
2. The checker cannot see a DUPLICATE. It verifies every production var is PRESENT and says nothing about a name appearing twice, so both concurrent fixes above passed it while adding a second entry — the same blind spot check-issue-index-append-only.py has, and the reason #2290 exists. A len(set(names)) == len(names) assertion would close it.

Found while writing KV-DSV4-MULTICACHE W5's design section (#2323). Owning row: PERF-QWEN35-STAGE-WEIGHTS.