Idea: show connection profiles in the Data Catalog and switch between them at runtime

[scantinibudden]

The problem

I work against several databases (local dev, staging, a few side projects). Profiles make each one easy to launch, but a Harlequin session is bound to a single connection: to look at a different database I have to quit and relaunch with a different -P. Coming from database extensions in GUI editors (SQLTools-style), the thing I miss most is seeing my connections in one place and hopping between them.

Proposal

Surface config profiles as the top level of the Data Catalog, with one profile active at a time:

┌─ Data Catalog ─────────────┐
│ ▸ local        (active)    │
│   ▸ dev db                 │
│     ▸ public               │
│       ▸ users              │
│ ▸ staging                  │
│ ▸ side-project             │
└────────────────────────────┘

1. harlequin launched with no conn_str and no default profile starts disconnected: an empty editor, and the catalog listing the configured profiles.
2. Selecting a profile node connects to it and makes it the active connection. Queries, autocomplete, history, and transaction mode all follow the active profile — exactly as today.
3. Switching profiles disconnects the old connection. The old profile's subtree can remain browsable from the existing catalog cache, marked stale until reactivated.

Explicitly not proposing concurrent live connections or per-tab query routing — one live connection at a time keeps the execution model untouched.

Alternatives considered

• Status quo: quit + relaunch with -P <name>. Works, but loses editor state and interrupts flow.
• Full multi-connection (several live connections, per-query routing). Much larger change to the app's execution model; I don't think the payoff justifies it, and it can always be layered on later if there's demand.

Implementation notes

This looks fairly contained: profile → adapter resolution already exists in the CLI and is reusable at runtime, and the catalog cache is already keyed by connection hash, so switching back to a previously-visited profile is instant. I'd be happy to implement it — likely as two small PRs (start-disconnected, then runtime switching) — but wanted to check the design direction with you first this time. Very open to a different UX (e.g. a command-palette-style switcher instead of tree nodes) if you'd rather keep the catalog as-is.