Define provider eligibility for doctor fallback

**What problem would this solve?**

Doctor can consider registered providers when the selected provider fails, but registration, explicit configuration, and local discoverability are different trust signals. We need a clear contract for which providers Doctor may probe and persist as a fallback.

**What would a good outcome look like?**

Doctor contacts only providers the user has configured or explicitly consents to probe. A successful fallback is not persisted until the user understands which endpoint and provider will receive later prompts. Headless, CLI, Desktop, scheduled, and ACP behavior should use the same eligibility rule.

**Possible approaches**

- Restrict automatic fallback to providers whose inventory reports configured.
- Show discoverable local providers separately and require confirmation before probing or selecting them.
- Define whether loopback defaults count as configured, discovered, or unavailable.
- Preserve a noninteractive mode with explicit configuration rather than implicit probing.

**Additional context**

Acceptance coverage should include a clean configuration, an explicitly configured local provider, an unavailable configured provider, and consistent legacy/state-machine behavior.

- [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 concerns the Doctor component's fallback provider logic. Start by locating the Doctor module and its provider selection/fallback code. Review how providers are registered, configured, and discovered. Define the eligibility contract by examining inventory reporting and user consent flows. Ensure tests cover clean configs, explicit local providers, unavailable providers, and legacy state-machine behavior.

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