[codex] Sync refreshed provider service models

[mimeding]

Business rationale

Custom OpenAI-compatible providers can add models while Osaurus is running. After #1020, the picker refreshes visible model lists on open; this follow-up keeps the backing provider service in sync too, so a model shown as available is also reflected by the service that handles requests. That protects trust in the local multi-provider harness.

Coding rationale

• Build on refresh model picker when new models/providers are added #1020's refreshConnectedProviders/refetchModels path rather than keeping a second refresh API.
• Update the existing RemoteProviderService actor only after the merged model list actually changes, preserving throttling/coalescing behavior and avoiding reconnects.
• Add a process-wide remote-provider test lock because Swift Testing .serialized only serializes tests within one suite; cross-suite singleton/notification races made ModelPickerItemCacheTests fail in full-suite runs while passing in isolation.
• Keep UI behavior unchanged; this PR is service state plus test isolation.

What changed

• refetchModels(providerId:) now updates the connected service's model snapshot when provider state changes.
• Added RemoteProviderTestLock.
• Wrapped remote-provider refresh and model-picker cache tests that share provider/cache singletons.

Validation

• swift build --package-path Packages/OsaurusCore
• swift build -c release --package-path Packages/OsaurusCore
• swift test --package-path Packages/OsaurusCore
• swift test --package-path Packages/OsaurusCore --filter RemoteProviderManagerRefreshTests
• swift test --package-path Packages/OsaurusCore --filter "RemoteProviderManagerRefreshTests|ModelPickerItemCacheTests"
• xcrun swift-format lint --strict Packages/OsaurusCore/Managers/RemoteProviderManager.swift Packages/OsaurusCore/Tests/Helpers/RemoteProviderTestLock.swift Packages/OsaurusCore/Tests/Model/ModelPickerItemCacheTests.swift Packages/OsaurusCore/Tests/Provider/RemoteProviderManagerRefreshTests.swift
• swiftlint lint --strict Packages/OsaurusCore/Managers/RemoteProviderManager.swift Packages/OsaurusCore/Tests/Helpers/RemoteProviderTestLock.swift Packages/OsaurusCore/Tests/Model/ModelPickerItemCacheTests.swift Packages/OsaurusCore/Tests/Provider/RemoteProviderManagerRefreshTests.swift
• git diff --check

Non-scope

• Does not change picker UI refresh behavior from refresh model picker when new models/providers are added #1020.
• Does not add a second provider refresh API.
• Does not change provider discovery or connection policy.

Residual risks

• The service snapshot is still only as fresh as the throttled picker-open refresh path.

[mimeding]

@tpae quick maintainer-facing summary of the current CI situation and the requested next step.

Current state

• main is red after refresh model picker when new models/providers are added #1020. The failing test-core run is the provider/model-picker race cluster: RemoteProviderManagerRefreshTests plus ModelPickerItemCacheTests.notificationBurst_doesNotTransientlyEmptyItems.
• This PR ([codex] Sync refreshed provider service models #1025) is the focused follow-up for that exact failure class.
• [codex] Sync refreshed provider service models #1025 is currently CLEAN and all checks are green: test-core, test-cli, swiftlint, shellcheck, and Release Drafter.
• The same red base is making several otherwise unrelated PRs look broken, including [codex] Add ExternalOfficeRuntime detection #1022, [codex] Add PresentationDocument typed representation #1023, [codex] Document high-fidelity business file workflows #1024, [codex] Fix scheduled state leaking into new chats #1018, and auto speak tts in chat #1026.

What is required

1. Please review and merge [codex] Sync refreshed provider service models #1025 first, or ask for a specific code change here if anything in the provider-service synchronization approach is not acceptable.
2. After [codex] Sync refreshed provider service models #1025 lands on main, I will rebase/rerun the affected PRs and update their status comments/checks.
3. I will not open the prepared follow-up PRs for I cant use tools, and I've granted all permissions #823 and deepseek tool calls fail with HTTP 400 (missing reasoning_content) #959 until the full local/CI gate is clean on top of the fixed base.

Why this should be first

Rerunning the red PR checks before this lands will mostly reproduce the same shared failure. Merging the green base fix first should turn those PRs back into meaningful signal: anything still red afterward is branch-specific and can be debugged cleanly.

Separate note: #958 is a different external/draft failure (EventSource module-resolution errors) and should be handled independently from this provider/model-picker race.