bug(slm-llm): renaming or removing an LLM provider orphans its stored API key #17858

Problem

The SLM admin LLM settings store each provider's API key as a secret matched to the provider by name (llm:provider:<name>:api_key, with the vault id cached in the provider entry). Since #17846 the key is never sent to the client, so the settings page cannot re-show or carry it.

• Rename: saving a provider under a new name finds no stored entry for the new name. It is saved with no key, and the old entry, with its secret reference, is dropped from llm_providers. The key is unreachable from the UI and its vault secret is orphaned. (Before fix(slm-secrets): stop sending LLM provider keys to the client, so a save cannot overwrite them (#17826) #17846 a rename stored the display mask, which was broken in a different way.)
• Removal: removing a provider drops its entry, but delete_provider_api_key is never called, so its vault secret is orphaned.
• The UI has no "a key is set" indicator, so a user cannot tell a provider with a stored key from one without.

Found by the code-reviewer pass on #17846.

Constraints

• Deleting a vault secret on removal is a credential deletion. A user removing a provider in the UI is a human-initiated action, which is different from an agent cleanup under Umbrella: SLM Data hygiene page — detect and safely clean up orphaned data across services #17038. But on installations hit by bug(slm-secrets): saving LLM settings overwrites every provider API key in the vault with its masked display string #17826 the stored vault id may point at a mask-holding row while the original key sits in an orphaned row (see bug(slm-secrets): saving LLM settings overwrites every provider API key in the vault with its masked display string #17826, bug(secrets): the envelope store allows duplicate (owner_vault, name), so first-time secret creation is not idempotent #17850). The design must say which rows a removal deletes, and must never delete by name.
• Matching is by name. Rename support needs either a stable provider id, or carrying the old name's reference to the new name in the same save.

Acceptance criteria

• A rename keeps the stored key, or is refused with a message saying the key must be re-entered. A test covers it.
• Removing a provider deletes exactly the secret its entry references (by id, never by name), logged. A test proves no other same-name row is touched.
• The GET view carries a boolean api_key_set, and the UI shows it (i18n in all locales).