[Fix] Reject LoRA adapters on non-PyTorch backend

[zcxGGmu]

Motivation

When lmdeploy serve api_server resolves to the TurboMind backend, --adapters is currently accepted but not applied because LoRA adapters are PyTorch-backend only. This can make the server start successfully while adapter model names are unavailable, which matches the confusion reported in #3594.

Refs #3594

Modification

• Add an early CLI validation for serve api_server: if adapters are provided after backend resolution and the selected backend is not pytorch, raise a clear ValueError asking the user to set --backend pytorch.
• Add CLI unit coverage for both rejecting TurboMind and allowing PyTorch.

BC-breaking (Optional)

No supported behavior is removed. Invalid --adapters + non-PyTorch backend combinations now fail early with an explicit message instead of being silently ignored.

Use cases (Optional)

Users serving LoRA adapters should launch with --backend pytorch, for example:

lmdeploy serve api_server /path/to/model --backend pytorch --adapters mylora=/path/to/lora

Checklist

1. Pre-commit or other linting tools are used to fix the potential lint issues.
   • python -m pre_commit run --files lmdeploy/cli/serve.py tests/test_lmdeploy/cli/test_serve.py
2. The modification is covered by complete unit tests. If not, please add more unit tests to ensure the correctness.
   • python -m pytest tests/test_lmdeploy/cli/test_serve.py tests/test_lmdeploy/serve/test_generation_config.py -q
3. If the modification has a dependency on downstream projects of a newer version, this PR should be tested with all supported versions of downstream projects.
   • N/A
4. The documentation has been modified accordingly, like docstring or example tutorials.
   • N/A; this is a CLI validation/error-message fix.

[lvhan028]

These UT additions don't add much value. Please remove it.