Configure and switch between multiple Galaxy instances in Orbit (e.g. usegalaxy.org and .eu)

## Motivation

Users work across multiple Galaxy servers — **usegalaxy.org**, **usegalaxy.eu**, **usegalaxy.org.au**, institutional instances — each with its own account/API key, histories, and tool availability. Orbit should let you configure several Galaxy instances and switch the active one, instead of being tied to a single server.

## Current state

The **data model already supports multiple named profiles** — the gap is the UI:

- Config: `~/.loom/config.json` → `galaxy: { active: string, profiles: Record }`.
- `extensions/loom/profiles.ts` manages named profiles (`loadProfiles`, `saveProfile`, `switchProfile`); `/connect ` and `/profiles` switch/list them from chat.

But the **Orbit UI is single-server**:
- Welcome screen writes one hardcoded profile: `profiles: { default: { url, apiKey } }` (`app/src/renderer/app.ts` ~L899).
- Preferences exposes a single URL + key (`prefs-galaxy-url` / `prefs-galaxy-key`, `app.ts` ~L3032) editing that one `default` profile, plus a Disconnect button.
- There is no UI to add a second server, see the list, or pick which is active. Power users can hand-edit `config.json` or use `/connect` in chat, but that isn't discoverable.

So today, `galaxy.profiles` almost always has exactly one entry named `default`.

## Proposed

Surface the existing multi-profile model in the Orbit UI:

1. **Preferences → Galaxy: a list of servers.** Add / edit / remove named Galaxy instances, each with a label, URL, and its own API key (encrypted at rest via safeStorage, like the current single key). Mark one active.
2. **A server switcher.** Let the user change the active Galaxy instance — ideally from the footer (next to the Galaxy indicator) and/or Preferences. Switching re-points `GALAXY_URL` / `GALAXY_API_KEY`, re-registers the Galaxy MCP server, and restarts the brain (the same path `/connect` already uses via `ctx.reload`).
3. **Presets** for common servers (usegalaxy.org, usegalaxy.eu, usegalaxy.org.au) so adding one is one click + paste key.
4. **Welcome flow** unchanged for first-run (add one to start); additional servers are added later in Preferences.

## Considerations

- **Per-server binding/history.** A notebook's `loom-galaxy-page` binding and history belong to a *specific* server — pushing/pulling or opening a history must target the server it was created on, not just the currently-active one. Guard against cross-server mismatch (e.g. a notebook bound to `.org` while `.eu` is active). The history-link feature (#240) already builds the URL from the active profile's origin — that needs to become binding-aware here.
- **Switching mid-session** should behave like `/connect` (brain restart + MCP re-register), and warn if there's in-flight work bound to the current server.
- **Liveness per server** — the footer indicator (#362) should reflect the *active* server's reachability/auth, and ideally show which server is active.
- Keep each profile's key encrypted; only the active profile's URL/key sync to the brain env.

## Acceptance criteria

- [ ] The Orbit UI can add, edit, and remove multiple Galaxy servers, each with its own URL + API key.
- [ ] The user can switch the active Galaxy instance from the UI; the brain + MCP follow the switch.
- [ ] The footer/UI shows which Galaxy server is active.
- [ ] Notebook Galaxy bindings/histories remain tied to the server they were created on (no cross-server push/open).
- [ ] Existing single-`default`-profile configs migrate/keep working.

## Related

- `extensions/loom/profiles.ts`, `/connect` + `/profiles` (existing multi-profile plumbing).
- #362 — footer indicator should reflect the active server's liveness.
- #240 — Galaxy history link (build URL from the bound server, not just the active one).

Start in app/src/renderer/app.ts around the welcome and Galaxy preference flows, then read extensions/loom/profiles.ts and the existing /connect and /profiles handling. Trace how switching reloads the brain and registers MCP, and inspect the binding logic related to #240 and liveness behavior in #362. Done means the UI manages multiple encrypted profiles, switches safely, preserves server-specific bindings, and keeps single-profile configs working.

Written by the indexing model from the issue text.