fix(provider): pin auto-enabled providers to top

[ousugo]

🚨 Branch strategy — read before opening this PR

The v2 refactor has merged into main, so main is the default branch for active development (v1 and v2 code currently coexist there — expect large, breaking changes).

• Active development (features, refactors, optimizations, fixes for the current codebase) → target main (the default base).
• v1 maintenance (hotfixes and subsequent v1 releases) → branch from and target v1, not main.

A v1 fix does not auto-carry to main: if the same bug exists on main, open a separate forward-port PR targeting main. Before touching subsystems being replaced, read docs/references/data/ and watch for @deprecated markers — they flag code being deleted.

What this PR does

Before this PR:
Providers that were automatically enabled after entering an API key could remain in their previous list position when the providers cache was not ready, because the reorder call could silently no-op.

After this PR:
Auto-enabled providers are moved to the top only after the provider list is ready for reordering. The shared enablement flow now asserts reorder readiness before enabling, uses a common move-to-first hook, and covers manual provider enablement as well.

Fixes # None

Why we need it and why it was done in this way

The following tradeoffs were made:
The provider is not enabled when the provider list is not ready to reorder. This avoids the inconsistent state where the provider is enabled but not pinned to the top.

The following alternatives were considered:
Allowing the enable operation to succeed and retrying reorder later was considered, but that would preserve a transient inconsistent UI state and require additional retry orchestration. Keeping the enable and reorder precondition in one flow is simpler and makes failure explicit.

Links to places where the discussion took place: N/A

Breaking changes

None

If this PR introduces breaking changes, please describe the changes and the impact on users.

Special notes for your reviewer

This PR intentionally leaves broader connection-check races and stale closure edge cases for a separate follow-up. The focused fix is to remove the silent cache-not-ready no-op from the provider auto-enable and manual enable paths.

Validation:

• pnpm lint passed.
• ProviderSettings-related renderer tests passed in the full test run, including useProviderEnable, useMoveProviderToFirst, useProviderAutoModelSync, useProviderConnectionCheck, providerEnablement, and model pull reconcile tests.
• Full pnpm test ran after retrying the local sqlite/better-sqlite3 issue, but the overall suite still has unrelated Windows path/mock failures in main-process tests.

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

• Branch: This PR targets the correct branch — main for active development, v1 for v1 maintenance fixes
• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Documentation: A user-guide update was considered and is present (link) or not required. Check this only when the PR introduces or changes a user-facing feature or behavior.
• Self-review: I have reviewed my own code (e.g., via /gh-pr-review, gh pr diff, or GitHub UI) before requesting review from others

Release note

Fixed an issue where providers enabled after entering an API key might not move to the top of the provider list.