fix(cli): persist provider on global model switch

[helix4u]

What does this PR do?

Ensures classic CLI /model ... --global switches always persist the resolved provider together with the selected model.

The two classic CLI persistence paths used result.provider_changed, which compares the target provider with the current in-memory runtime provider, as a gate for writing model.provider. If the session already used the target provider while config.yaml still contained a stale provider, Hermes persisted the new model but left the stale provider on disk. The next launch then loaded a mismatched model/provider tuple.

Successful global switches now persist result.target_provider unconditionally, matching the existing gateway persistence behavior. Runtime transition behavior can still use provider_changed; durable configuration cannot.

Related Issue

Related to #60903. That PR is conflicting and includes broader endpoint-helper and provider-alias changes. Current main already synchronizes base_url and api_mode; this PR isolates the remaining provider-persistence defect.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• Always write model.provider for persisted picker-based model switches.
• Always write model.provider for persisted typed /model switches.
• Add regressions for both paths when provider_changed is False.

How to Test

1. Start with a runtime already using the requested target provider while persisted model.provider is stale.
2. Perform a typed or picker-based global model switch.
3. Verify the persisted tuple includes both the new model and result.target_provider.
4. Run scripts/run_tests.sh -j 4 tests/hermes_cli/test_25106_global_switch_persists_base_url_api_mode.py -q.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: Windows 11, direct single-process regression probes

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — N/A, this restores the existing global-persistence contract
• I've updated cli-config.yaml.example if I added/changed config keys — N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — no platform-specific behavior
• I've updated tool descriptions/schemas if I changed tool behavior — N/A

Screenshots / Logs

Focused local validation:

cli provider persistence direct regressions: PASS
✓ No Windows footguns found (2 file(s) scanned).
git diff --check: PASS
python -m py_compile cli.py tests/hermes_cli/test_25106_global_switch_persists_base_url_api_mode.py: PASS

The full pytest suite was not run locally; GitHub CI owns full-suite coverage.