Please address the comments from this code review:

## Overall Comments
- In `ProviderXiaomiTokenPlan.__init__`, accessing `key[0]` will raise an IndexError when `key` is an empty list, so add a guard (e.g., check for a non-empty list or falsy value) before deriving `actual_key`.
- The Xiaomi model list is duplicated in both `xiaomi_source.py` and `xiaomi_token_plan_source.py`; consider centralizing this constant in a shared module to keep the supported models in sync.

## Individual Comments

### Comment 1
<location path="astrbot/core/provider/sources/xiaomi_token_plan_source.py" line_range="49-51" />
<code_context>
+        provider_config["api_base"] = "https://token-plan-cn.xiaomimimo.com/anthropic"
+
+        # Xiaomi Token Plan requires the Authorization: Bearer <token> header.
+        key = provider_config.get("key", "")
+        actual_key = key[0] if isinstance(key, list) else key
+        provider_config.setdefault("custom_headers", {})["Authorization"] = (
+            f"Bearer {actual_key}"
+        )
</code_context>
<issue_to_address>
**issue:** Guard against empty or missing Xiaomi Token Plan keys before setting the Authorization header.

If `key` is `[]` (default or from user config), `actual_key` becomes an empty string and you still send `Authorization: Bearer `. That hides configuration issues and leads to confusing 401s. Please handle empty/missing keys explicitly (e.g., raise a configuration error or skip the header and log a clear warning) so misconfigurations are surfaced early and invalid headers aren’t sent.
</issue_to_address>

### Comment 2
<location path="astrbot/core/provider/sources/xiaomi_token_plan_source.py" line_range="6-12" />
<code_context>
+
+from ..register import register_provider_adapter
+
+XIAOMI_TOKEN_PLAN_MODELS = [
+    "mimo-v2.5-pro",
+    "mimo-v2.5",
+    "mimo-v2-pro",
+    "mimo-v2-omni",
+    "mimo-v2-flash",
+]
+
+
</code_context>
<issue_to_address>
**suggestion:** Avoid duplication of Xiaomi model lists across providers to reduce drift risk.

The Xiaomi Token Plan and standard Xiaomi provider each maintain their own, nearly identical model lists. To avoid them drifting out of sync when models change, centralize this list (e.g., in a shared module/constant) and reuse it in both providers, or derive one from the other so updates happen in only one place.

Suggested implementation:

```python
from astrbot import logger
from astrbot.core.provider.sources.anthropic_source import ProviderAnthropic

from ..register import register_provider_adapter
from .xiaomi_models import XIAOMI_MODELS

XIAOMI_TOKEN_PLAN_MODELS = XIAOMI_MODELS

```

To fully avoid duplication and drift, you should also:
1. Create a new module `astrbot/core/provider/sources/xiaomi_models.py` that defines the single source of truth, for example:
   - `XIAOMI_MODELS = ["mimo-v2.5-pro", "mimo-v2.5", "mimo-v2-pro", "mimo-v2-omni", "mimo-v2-flash"]`
2. Update the standard Xiaomi provider file (likely `astrbot/core/provider/sources/xiaomi_source.py`) to:
   - Remove its local Xiaomi model list.
   - Import and use `XIAOMI_MODELS` from `.xiaomi_models` instead.
3. If the token plan provider needs a subset/superset in the future, derive `XIAOMI_TOKEN_PLAN_MODELS` from `XIAOMI_MODELS` (e.g., filtering) rather than hardcoding a separate list.
</issue_to_address>