Add qwen3-coder-30b-a3b-instruct model to resolve_model_config.py

[juanmichelini]

Summary

Adds the model litellm_proxy/Qwen3-Coder-30B-A3B-Instruct with id qwen3-coder-30b-a3b-instruct to the expected models in resolve_model_config.py.

Fixes #1901

Changes

• Added new model entry qwen3-coder-30b-a3b-instruct to the MODELS dictionary in .github/run-eval/resolve_model_config.py
• Added the model to EXPECTED_MODELS list in tests/github_workflows/test_resolve_model_config.py

Checklist

• If the PR is changing/adding functionality, are there tests to reflect this?
• If there is an example, have you run the example to make sure that it works?
• If there are instructions on how to run the code, have you followed the instructions and made sure that it works?
• If the feature is significant enough to require documentation, is there a PR open on the OpenHands/docs repository with the same branch name?
• Is the github CI passing?

@juanmichelini can click here to continue refining the PR

[all-hands-bot]

Overall, the changes look good! The model entry follows the correct structure and tests were properly updated. I have one minor observation about model path consistency.

[all-hands-bot]

🟡 Suggestion: The model path uses a direct format (litellm_proxy/Qwen3-Coder-30B-A3B-Instruct) without a provider prefix, while other Qwen models in this file use provider-specific paths:

• qwen-3-coder uses litellm_proxy/fireworks_ai/qwen3-coder-480b-a35b-instruct
• qwen3-coder-next uses litellm_proxy/openrouter/qwen/qwen3-coder-next

Is Qwen3-Coder-30B-A3B-Instruct configured directly in the LiteLLM proxy, or should this follow the provider pattern like the other Qwen models? If the direct path is correct (e.g., it's a custom endpoint), then this is fine as-is.