[Feature request] Let Galaxy instances host the MCP server so Orbit doesn't need a local `uvx`

**Context**
Orbit (release install, `linux-arm64`, Jetson) currently launches `galaxy-mcp` as a local subprocess via `uvx` — the `command: "uvx"` MCP entry that gets written into `~/.pi/agent/mcp.json`. When `uvx` isn't available on the host (or the bundled one isn't found), Loom surfaces:

> *"I couldn't inspect the Galaxy history itself because the Galaxy MCP connection failed locally (uvx missing)"*

The codebase already tries to mitigate this by shipping `uv` under `resources/uv/` in packaged builds (see `app/forge.config.ts:208–249` and `app/src/main/agent.ts:74–82`), but the local-subprocess model still leaves a few rough edges for end users: a per-client Python runtime, a per-client galaxy-mcp version, an extra failure surface on platforms where the bundle doesn't resolve, and a `uvx`-spawn delay on every brain start.

**Proposal**
If the Galaxy instance hosted the MCP server itself — exposed over the same HTTPS endpoint as the Galaxy API, behind the existing API key auth — Orbit could connect to it as a remote MCP transport (HTTP/SSE/WebSocket) instead of spawning a subprocess. Concretely:

- Galaxy ships (or proxies to) a managed `galaxy-mcp` endpoint, e.g. `https:///api/mcp`.
- Orbit's mcp.json entry for `galaxy` becomes a `url:` entry pointing at that endpoint, with the existing `${GALAXY_API_KEY}` used as the bearer.
- The local `uvx galaxy-mcp` path remains as a fallback for self-hosted / dev setups that want the client-side server.

**Why this would help**
- Removes the `uv`/Python dependency from the client entirely (no bundling, no PATH plumbing in `agent.ts`).
- Server-side galaxy-mcp version is pinned to the Galaxy instance — no client/server skew.
- One less subprocess in Orbit's process tree; faster cold start.
- Easier to operate Orbit on platforms where bundling Python tooling is painful (ARM64 distros, sandboxed installs, etc.).

**Out of scope**
I'm not asking to remove the local-subprocess path — just to make remote MCP the preferred path when the Galaxy instance offers it. The local fallback stays useful for dev and for Galaxy instances that haven't adopted server-side MCP yet.

Related: #148 (separate report — Electron postinstall failure on the same host).

Start by reading the MCP configuration generation in app/src/main/agent.ts:74–82 and the packaged uv setup in app/forge.config.ts:208–249, then inspect the generated ~/.pi/agent/mcp.json entry. Define how Orbit detects and prefers a Galaxy-hosted endpoint, preserves the local uvx fallback, and passes the existing API key; done means remote MCP works when available without breaking self-hosted or development setups.

Written by the indexing model from the issue text.