[ci] fix: move torch and torch_npu install order in ascend dockerfile to ensure installed version correct

[FightingZhen]

What does this PR do?

move torch and torch_npu install order to ensure installed version correct

Checklist Before Starting

• Search for similar PRs. Paste at least one query link here: ...
• Format the PR title as [{modules}] {type}: {description} (This will be checked by the CI)
  • {modules} include fsdp, megatron, sglang, vllm, rollout, trainer, ci, training_utils, recipe, hardware, deployment, ray, worker, single_controller, misc, perf, model, algo, env, tool, ckpt, doc, data
  • If this PR involves multiple modules, separate them with , like [megatron, fsdp, doc]
  • {type} is in feat, fix, refactor, chore, test
  • If this PR breaks any API (CLI arguments, config, function signature, etc.), add [BREAKING] to the beginning of the title.
  • Example: [BREAKING][fsdp, megatron] feat: dynamic batching

Test

Not related.

API and Usage Example

Not related.

Design & Code Changes

Not related.

Checklist Before Submitting

Important

Please check all the following items before requesting a review, otherwise the reviewer might deprioritize this PR for review.

• Read the Contribute Guide.
• Apply pre-commit checks: pre-commit install && pre-commit run --all-files --show-diff-on-failure --color=always
• Add / Update the documentation.
• Add unit or end-to-end test(s) to the CI workflow to cover all the code. If not feasible, explain why: ...
• Once your PR is ready for CI, send a message in the ci-request channel in the verl Slack workspace. (If not accessible, please try the Feishu group (飞书群).)

[gemini-code-assist]

Code Review

This pull request moves the installation of torch and torch_npu to the end of the installation sequence in the Dockerfiles. This is a common strategy to ensure a specific package version is present, but it carries the risk of creating an environment with inconsistent dependencies, as other packages might rely on a different version of torch. This can lead to runtime errors. I've added comments with a suggestion to include pip check after the installations to verify dependency compatibility and fail the build early if any conflicts are found. This will make the Docker images more robust.