Define classifier model-mapping precedence over custom endpoints

**What problem would this solve?**
Prompt and command classifiers can be configured with custom endpoints, while deployments can later provide model mappings. Today the settings UI can display or imply that a mapped model is active—and can hide custom endpoint controls—while backend resolution still prefers retained custom model or endpoint state. That makes the effective destination receiving prompt or command content different from the destination administrators and users see. We need one precedence and migration contract for both classifier types.

**What would a good outcome look like?**
Define whether deployment mappings are authoritative or whether user custom endpoints remain valid overrides. The settings UI, persisted configuration, and backend scanner must all resolve and display the same effective provider/model/endpoint. Applying or removing mappings must migrate both prompt and command classifier state atomically, and obsolete credentials must not remain silently active.

The verification plan should cover: adding a mapping while an enabled custom endpoint/token remains stored; prompt and command mappings independently; multiple mapped choices; removing a mapping; application restart; and the effective destination shown in settings versus the client the backend instantiates.

**Possible approaches**
- Make deployment mappings authoritative and atomically replace or quarantine retained custom endpoint/model state.
- Preserve custom override precedence but keep its controls and effective destination visibly active.
- Introduce one backend-owned effective-classifier configuration API that the UI renders instead of reimplementing precedence.

Endpoint-origin credential rotation is independently valuable, but it does not resolve a mismatch between displayed mapping authority and runtime destination.

**Additional context**
The shared scanner is used by both legacy and state-machine agent paths, so the agreed contract and regressions must cover both.

- [x] I have verified this does not duplicate an existing feature request

Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).

The issue involves the shared scanner used by legacy and state-machine agent paths. Start by locating the classifier configuration logic, likely in a module handling prompt and command classifiers. Examine how model mappings and custom endpoints are currently resolved. The verification plan outlines specific scenarios to test, such as adding a mapping while a custom endpoint is stored. Focus on understanding the existing precedence logic before proposing changes.

Escrito por el modelo de indexación a partir del texto del issue.