fix(ci): keep the transformers<5.0 pin through the package install

[he-yufeng]

The pin line in the CUDA path runs before pip install ., but pip keeps no constraints across invocations. The package install then re-resolves trl (floor transformers>=4.56.2) against framework.txt's <5.15.0 and jumps to transformers 5.14.1, after which the suite dies importing transformers.models.gemma3. Every PR is red on this right now (confirmed on mine and on #9854, same error in the same step).

Carrying the pin into the package install keeps the resolver on the 4.x line the suite is written for. Verified with the actual resolver: trl==0.29.1 + transformers<5.0 in one run selects transformers 4.57.6, which satisfies trl's floor and keeps gemma3 importable.

The NPU path already carries the pin inside its own command and is untouched. Whether framework.txt itself should drop <5.15.0 for users is a bigger support-range question I left alone here.

[RerankerGuo]

I traced the full failing run and found a second resolver mutation that this patch does not cover. In run 31179195838, the initial pin correctly installs Transformers 4.57.6. Later, tests/tuners/test_merged_linear.py loads damo/nlp_structbert_sentence-similarity_chinese-base with remote code; that model installs its own requirements (huggingface-hub==0.25.*, transformers==4.48.3) into the shared test environment. The log then shows Successfully installed ... transformers-4.48.3, and only afterward test_gemma3_template.py fails with ModuleNotFoundError: transformers.models.gemma3.

The same sequence appears in the five currently red PR runs (#9850, #9852, #9859, #9870, #9871). Therefore carrying transformers<5.0 into pip install . is useful for the initial install but will not make these runs green. The fix also needs to prevent/isolate the remote StructBERT requirements install, or restore the supported dependency set after that suite. Merely moving the Gemma import would mask the shared-environment corruption.