Aliyun key hot reload

This patch closes two key-rotation gaps in the production Chat API without storing any credential in Git:

video_gateway_api_key() prefers a protected *_API_KEY_FILE on every call, so the AI skill router cannot keep using the startup-cached value.
CodexAppServerProcess fingerprints the protected provider key before every request. When the file changes and no request is pending, it replaces only the persistent Codex child and resumes the existing thread.

Production base hashes used by this patch:

chat_api.py: de81004c50a96fdf2e0064340edab213139da6ef304014c1586a4059871a8a1b
codex_app_server_runtime.py: 13c4463c6226840ae1a751279b4ec830796fb8cb46e2491f245bbdfebc71dfb9

Deployed hashes on 2026-09-08:

chat_api.py: 878e4e0d4c7e5b91190f53b64dccca3154fa3a189ea006d2182d0930a9079c4f
codex_app_server_runtime.py: 1ba04cbd15842114c77e89e71c7f36a43a24bc77bac22fd88eeb5d714b573cb3

The deployment was gated on zero queued/running durable tasks and zero real Chat API requests in the previous five minutes. A backup was created at /opt/dalongxia-chat-api/backups/aliyun-key-hot-reload-mLOvGl before the service restart.

Verification:

the supplied key file fingerprint matched the protected server key file;
a direct qwen3-vl-plus request returned HTTP 200;
the production health endpoint returned HTTP 200 after restart;
the next two Codex shadow records completed successfully, while the three immediately preceding records had failed with CodexAppServerError;
no post-deployment InvalidApiKey or API-key is blocked error appeared.