feat: upgrade QWeather API authentication

[tairan]

Summary

• replace the weather page scraper with QWeather GeoAPI v2 and Weather API v7 JSON calls
• support both X-QW-Api-Key and Ed25519 JWT authentication
• add encrypted manager-api credential storage backed by one project master key
• add manager-web secret upload/configuration and remove the bundled default API key

Verification

• manager-api focused tests: 8 passed
• xiaozhi-server weather tests: 6 passed
• manager-web i18n check and 8 unit tests passed; production build succeeded
• full manager-api suite: 127 passed; 5 existing integration tests require a local MySQL instance

Compatibility

Existing plaintext per-agent API keys remain readable. New secrets are encrypted when xiaozhi.secret.master-key / XIAOZHI_SECRET_MASTER_KEY is configured. Standalone YAML configuration supports the existing API-key flow and the new JWT flow.

[chentyke]

Hi tairan, thanks for the comprehensive weather plugin upgrade. I verified the Java and Python tests and the manager-web production build locally; they all passed. The QWeather API and JWT implementation also appears consistent with the official documentation.
Before merging, could you please address two compatibility issues?
The migration clears the old shared API key from sys_params, but existing agents may already have copied that key into ai_agent_plugin_mapping.param_info. Please remove api_key only from weather-plugin mappings where it exactly matches the old bundled key, while preserving user-provided keys.
manager-mobile does not yet support the new select, password, file, and visible_when field metadata. These fields currently fall back to plain-text inputs, so JWT private keys cannot be uploaded properly and secrets may be displayed in plain text. Please add the corresponding mobile controls, or disable JWT configuration on mobile for now and direct users to manager-web.
One additional security-hardening suggestion: after manager-web saves the configuration, the API key/private key remains in the page state. It would be safer to reload the redacted configuration or clear the sensitive fields while retaining only their configured/fingerprint status.
These issues should not require changing the overall design, and the fixes appear manageable. Once addressed, the PR should be in good shape to merge.