bug(slm-llm): the provider Test button cannot test a saved cloud provider, and the naive fix would exfiltrate its key #17845

Problem

The SLM admin LLM settings page's Test button cannot test a saved cloud provider.

autobot-slm-frontend/src/views/settings/admin/LLMSettings.vue testProvider() sends provider.api_key from browser state to POST /settings/admin/llm/test, and autobot-slm-backend/api/llm_config.py test_llm_connection uses request.api_key verbatim as the Bearer token.

• Before bug(slm-secrets): saving LLM settings overwrites every provider API key in the vault with its masked display string #17826 that value was the display mask (sk-a...b3f2), so every test of a saved provider authenticated with the mask and failed.
• After bug(slm-secrets): saving LLM settings overwrites every provider API key in the vault with its masked display string #17826 the key is never sent to the client, so the value is empty and the test goes out unauthenticated. Same outcome, now by design.

Why the obvious fix is wrong

"When api_key is empty, resolve the stored key by provider name" would send a stored secret to a client-supplied endpoint, behind ADMIN_CONFIG_READ (not WRITE). Anyone with read access could point the endpoint at a host they control and receive any provider's key as a Bearer header.

Fix

Testing a saved provider resolves the stored key server-side and uses the stored endpoint, ignoring any client-supplied endpoint for that case. A client-supplied key, used only with the client-supplied endpoint, remains the path for testing an unsaved provider.

Acceptance criteria

• Testing a saved provider with no key in the request authenticates with the stored key against the stored endpoint
• A request naming a saved provider with a different endpoint and no key never sends the stored key (test asserts the outbound request carries no Authorization header, or is refused)
• Testing an unsaved provider with a supplied key still works