Galaxy footer indicator reflects only config, not liveness — show amber/red on unreachable/failed calls

## Symptom

The agent reported the Galaxy connection had dropped, while the footer Galaxy indicator stayed **green**. Both were "right" — they measure different things — but to the user it reads as a contradiction / a broken indicator.

From the session: the agent said *"Galaxy access dropped during upload, but I have the paired FASTQs extracted locally; should I run fastp locally now, or do you want to fix/reconnect…"* (plus repeated "Not connected"). Meanwhile the footer dot stayed green. A direct check showed `usegalaxy.org` was actually reachable again (`/api/version` → HTTP 200), so the drop was a transient mid-upload failure.

## Root cause

The footer indicator is a **static config check, not a liveness check**. `refreshGalaxyStatus` (`app/src/renderer/app.ts:609`) sets green purely on:

```ts
const connected = !!(profile?.url && profile?.hasApiKey);
```

i.e. "a profile with a URL and a key is configured." It never pings Galaxy and never reacts to runtime call failures, so a dropped/timed-out/401 call can't turn it red. The code already acknowledges this — comment at `app.ts:901`: *"shows 'connected' while the brain rejects the credentials."*

So **green = configured**, not **green = reachable + authorized**. The agent, by contrast, sees real per-call results.

## Proposed fix

Make the indicator reflect **actual liveness**, with at least three visible states:

- **Green — connected:** a recent lightweight check succeeded (`/api/version`, or an authed `whoami`/`/api/users/current` to also validate the key).
- **Amber — configured but unverified / degraded:** a profile+key exist but the last check hasn't succeeded yet, or recent calls are failing intermittently.
- **Red — unreachable / unauthorized:** the liveness check fails (network/timeout) or returns 401/403 (bad/expired key).

Mechanics:
1. **Periodic lightweight ping** (e.g. every 30–60 s) of `/api/version` (reachability) and optionally an authed endpoint (key validity), updating the dot + tooltip ("last checked 12 s ago — OK" / "unreachable" / "key rejected").
2. **React to real failures:** when a Galaxy MCP/API call fails at runtime (the exact thing the agent saw), flag the indicator amber/red immediately rather than waiting for the next ping. (Ties into the same provider/connection-status surfacing as #235.)
3. Tooltip should distinguish *unreachable* (network/server) from *unauthorized* (key) so the user knows whether to retry vs re-enter the key.

## Acceptance criteria

- [ ] The indicator turns amber/red when Galaxy is unreachable or the key is rejected — it does not stay green through failures.
- [ ] Green means a recent live check actually succeeded, not merely that a profile is configured.
- [ ] Tooltip distinguishes unreachable vs unauthorized vs OK (with a last-checked time).

## Related

- #235 — silent provider fallback / surfacing connection problems in the UI (same theme).
- `app/src/renderer/app.ts:609` (`refreshGalaxyStatus`) and the `:901` comment.
- #242 / #282 — transient failures during long Galaxy uploads (a common trigger for the "dropped" state the indicator misses).

Start in app/src/renderer/app.ts at refreshGalaxyStatus around line 609 and the connection-status comment around line 901. Trace the Galaxy MCP/API call failure path and related provider-status work in #235 before deciding where live checks and failure updates belong. Done means the footer distinguishes recent success, unreachable, and unauthorized states with an informative last-checked tooltip.

Written by the indexing model from the issue text.