fix(providers): resolve ProviderProfile identity consistently

[WolframRavenwolf]

A provider declared through ProviderProfile can be available at startup yet fail the shared CLI/gateway identity lookup. Resolve profile names and aliases through resolve_provider_full() while keeping built-in lookup free of plugin discovery. Preserve explicit configuration, built-in provider IDs, bare custom endpoints and display metadata.

This PR covers identity and configuration. Runtime transport-mode propagation remains separate work in #53055; this branch does not take over that implementation. Its discovery-fixture coverage is credited to david-bowiegxw, with the contributor mapping and Co-authored-by trailer retained. #34368 identified the model-switch lookup gap and is credited to Kyzcreig. #65956 overlaps the separate runtime-mode work.

The new test module is tests/hermes_cli/test_provider_profile_identity.py, avoiding the filename collision with #53055. Compatibility with that unmerged transport change is not asserted here.

Validation: 246 tests passed across model-switch custom providers, runtime provider resolution, profile identity, runtime transport precedence and CommandCode profile suites; scoped Ruff and git diff --check passed.

[teknium1]

Thanks for isolating the generic CLI identity gap; current resolve_provider_full() still reaches get_provider() without a ProviderProfile fallback (hermes_cli/providers.py:742-745, :477).

Problems

• hermes_cli/runtime_provider.py:2001-2032 makes profile_api_mode win over URL detection. Current main intentionally honors a selected provider's model.base_url (:2028-2032) and then detects the endpoint protocol (:2057-2062). With this PR, an auto-registered profile declaring (for example) anthropic_messages cannot switch to a configured OpenAI/xAI endpoint, because :2029 skips detection.

Suggested changes

• Make profile_api_mode a fallback only after explicit configured mode and _detect_api_mode_for_url(base_url), and add a regression covering a non-default profile mode plus a same-provider base-URL override requiring a different detected mode.
• The new switch test manually inserts ProviderConfig.extra; add coverage that exercises the auth auto-registration path in hermes_cli/auth.py:461-473 as well.

Automated hermes-sweeper review.

[teknium1]

Please keep _detect_api_mode_for_url(base_url) ahead of this profile fallback. model.base_url is intentionally honored for the configured provider, so an overridden endpoint may require a different protocol than the profile's default; the new if not profile_api_mode guard at line 2029 prevents that detection entirely.

[WolframRavenwolf]

Addressed the review points and coordinated the overlapping provider work in the rebased branch:

• plugin discovery is limited to the full CLI resolver, not get_provider()
• real auth auto-registration is exercised by the /model regression
• persisted config and URL detection win over the profile-declared api_mode; the profile remains the fallback for non-self-describing endpoints
• stale persisted modes from a different provider are rejected on the explicit-key path
• pooled, explicit-key, and no-pool routes are covered
• explicit user-provider IDs also beat matching profile aliases; bare custom semantics are preserved

Canonical provider test runner: 208 passed.

[WolframRavenwolf]

Fresh head-matched Devin review found one actionable integration mismatch: CLI identity accepted profiles that the auth bridge intentionally does not register.

Addressed in the latest head by applying the same auth_type == "api_key" plus non-empty env_vars eligibility contract in both paths, with focused regressions for no-auth and uncredentialed profiles.

Verification:

• canonical provider suite: 210 passed
• Ruff: passed
• contributor mapping gate reproduced locally: all author emails mapped

[WolframRavenwolf]

A delayed independent review found one additional provider-family edge case after the previous update: a persisted api_mode keyed by a registered ProviderProfile alias was not recognized as belonging to the canonical runtime provider.

Fixed test-first in the latest head:

• canonical and alias registry entries are compared through their shared ProviderConfig.id
• persisted alias configuration now wins on pooled, explicit-key, and no-pool API-key routes
• unrelated providers remain isolated
• bare custom behavior remains unchanged

Verification:

• canonical provider suite: 211 passed
• contributor-authored fix(providers): gate plugin api_mode by endpoint (#53054) #53055 commit remains separately preserved
• Ruff and git diff --check: passed

[teknium1]

Salvaged into #116853 (main 9f0cd9d773) by cherry-pick, so your commit 7d29404 (alias identity: persisted config applies to the canonical provider, _same_registered_provider) landed with your authorship; the 266-line test module was trimmed to three invariants. Thank you @WolframRavenwolf. Closing as landed.