feat: always require a named connection on login

[manojbajaj95]

Summary

Today the first connection for a provider is stored under the literal name default. A user-chosen name is only required when adding a second connection (via NamedConnectionDialog in the UI or --connection on the CLI). The default connection should be a property (ProviderMetadataRecord.default_connection) pointing at a named connection — not a connection whose name is "default".

Current behavior

• UI first-time connect posts connection=default (ui/src/components/dashboard/provider-views.tsx).
• requiresNamedLogin is true only when a "default" connection already exists (ui/src/lib/authsome-api.ts).
• Server connect handler falls back to "default" when no name is supplied (src/authsome/server/routes/ui.py).
• CLI login defaults --connection to "default" (src/authsome/cli/commands/core.py).
• ProviderMetadataRecord.default_connection defaults to "default" (src/authsome/auth/models/connection.py).
• Docs describe the default connection as literally named default (docs/site/guides/multiple-connections.mdx).

Proposed behavior

Always prompt for (or require) a user-chosen connection name when connecting a provider — including the first connection. That name becomes the stored connection_name. The provider's default is then set to that name via default_connection metadata, not by using "default" as the key.

Examples:

• User names first GitHub connection work → stored at vault:…:github:connection:work, default_connection = "work".
• User adds a second connection personal → stored separately; default_connection unchanged unless explicitly switched.
• Commands/API calls that omit --connection resolve via default_connection metadata (existing resolve_connection_name behavior), not by assuming a connection named "default" exists.

Scope

UI

• Always show the connection-name dialog (or inline name field) before starting OAuth/API-key flow, even when connectionCount === 0.
• Remove hidden connection=default form posts.
• Update provider detail "Connect" flow similarly (provider-detail-view.tsx).

CLI

• Require --connection <name> on authsome login, or prompt interactively when omitted (TBD — pick one and document).
• Stop defaulting --connection to "default".

Server / storage

• connect routes should reject or prompt when connection_name is missing or equals the reserved name default (if we deprecate that literal).
• On first connection save, set metadata.default_connection to the chosen name.
• resolve_connection_name / resolve_effective_connection should not assume a "default" connection record exists; fall back to default_connection metadata only.
• Consider migration for existing vaults that already have a default connection (rename? alias? keep reading "default" as legacy?).

Docs

• Update docs/site/guides/multiple-connections.mdx and any CLI reference to reflect named-first connections.

Acceptance criteria

• First provider connection always uses a user-supplied name, never the literal "default".
• default_connection metadata is set to the first connection's name automatically.
• Omitting --connection on read/export/get commands still resolves the provider default via metadata.
• UI and CLI flows both enforce the naming requirement consistently.
• Existing "default" connections have a documented migration or backward-compat path.
• Tests cover first-login naming, default resolution, and multi-connection flows.

Open questions

• Should "default" remain a reserved/legacy alias for backward compatibility, or be fully removed?
• Interactive CLI prompt vs hard requirement for --connection?
• Auto-suggest a name (e.g. provider name, account email) vs blank required field?

References

• ui/src/components/dashboard/provider-views.tsx (NamedConnectionDialog, requiresNamedLogin)
• src/authsome/server/routes/ui.py (connect_provider)
• src/authsome/server/credential_service.py (resolve_connection_name, set_default_connection)
• src/authsome/auth/models/connection.py (ProviderMetadataRecord)