fix(providers): derive new-connection default name from live names (closes #15006)

[toor11]

Summary

Adding a connection after deleting one no longer defaults to a name that collides with a live connection. With main/main-3 live (main-2 deleted), the modal proposed main-3 and the backend name-upsert silently overwrote it. It now proposes the first free slot (main-2).

Related Issues

• Closes fix(providers): adding a cookie connection can silently overwrite an existing one — count-based default name collides after a delete, and cookie rows upsert by name #15006
• Related to fix(dashboard): compute unique connection names from array to avoid overwrite (#11033) #11067 (added the names-array overload that this wires up), fix(ui): prevent silent overwrite of existing API key connections on … #6499, discussion GPT ACCOUNT ADDING PROBLEM #10861

Root cause

AddApiKeyModal derived its default name from connections.length (ProviderDetailPageClient.tsx:850 → ProviderModalsPanel → modal), but computeConnectionDefaultName has had a names-array overload since #11067 that the modal never used. After any delete, count no longer matches the highest suffix, so the generated name hits a live row and findExistingCookieConnection (src/lib/db/providers.ts:444, step 1 name-upsert) replaces it.

Change

• ProviderDetailPageClient passes live connection names; ProviderModalsPanel/AddApiKeyModal take existingConnectionNames?: string[] and use the names overload at both call sites (initial state + on-open reset). Single consumer chain, so the count prop is replaced, not kept alongside.
• Deliberately no backend change: same-name/different-credential upsert is intentional session-rotation behavior asserted by db-provider-cookie-dedup-3368.test.ts:112 ([Feature] Robust web-session and no-auth auto routing with incremental PR plan #3368/feat(mcp): web-session robustness — cookie dedup (PR6) + browser-pool observability (PR7) (#3368) #5121). The frontend fix removes the collision path.
• Changelog fragment docs/changelog/fragments/15006.md.

Validation

• Change type: UI
• New vitest suite modals/__tests__/addApiKeyModal-default-name-15006.test.tsx: fail→fix→pass verified (2 failed on the pre-fix file with expected 'main' to be 'main-2', 3/3 pass with the fix)
• Neighbor suite connModals.test.tsx: 20/20 pass
• Helper suites compute-connection-default-name-6499/11033: 7/7 pass
• npm run lint on touched files: clean (2 errors in ProviderDetailPageClient.tsx:8,95 and 1 dashboard-typecheck error in NoAuthAccountCard.tsx are pre-existing on the clean tip, verified via stash, left untouched)
• Reconciled with origin/release/v3.8.51

Tests Added Or Updated

• Added: src/app/(dashboard)/dashboard/providers/[id]/components/modals/__tests__/addApiKeyModal-default-name-15006.test.tsx

Coverage Notes

• Touched dashboard files are covered by the new modal test (name derivation at both mount and on-open paths).

Reviewer Notes

• Open design point from the issue left for you: whether a same-name/different-credential cookie add should ever be rejected as a conflict instead of upserting. I kept upsert intact because the rotation test depends on it; happy to implement the reject variant if you prefer.