[Feature request] Auto-discover installed Ollama models via /api/tags instead of a hardcoded list

**Context**
Orbit's Preferences → Model dropdown for the `ollama` provider currently ships a small, hardcoded set of model IDs. Two sources contribute to it:

- `app/src/main/ipc-handlers.ts:506–552` — `models:list-all` reads from pi-ai's bundled model registry (`getModels("ollama")`).
- `app/src/renderer/app.ts:2529–2532` — local fallback list (`qwen3-coder:30b`, `qwen3:8b`).

Neither source asks Ollama what's actually installed. If a user pulls a model that isn't in pi-ai's bundled list (e.g. `gemma4:12b`, `mistral-nemo`, anything new), it simply doesn't appear in the dropdown.

**Repro**
1. Install Ollama and pull a model that isn't on the hardcoded list, e.g. `ollama pull gemma4:12b`.
2. Confirm it's there: `curl -s http://localhost:11434/api/tags` returns it.
3. Open Orbit → Preferences → Provider: Ollama (local). The dropdown shows the hardcoded options only; `gemma4:12b` is absent.

**Workaround**
Edit `~/.loom/config.json` directly:

```json
"llm": {
"active": "ollama",
"providers": {
"ollama": { "model": "gemma4:12b" }
}
}
```

On next start the renderer's "custom entry" fallback (`app/src/renderer/app.ts:2546–2552`) renders the saved value as `gemma4:12b (custom)` and it becomes selectable. That works, but it's invisible to anyone who hasn't read the source.

**Proposal**
When the `ollama` provider is selected in Preferences, populate the model dropdown by hitting Ollama's local HTTP API:

```
GET http://localhost:11434/api/tags
```

The response already contains everything needed for a useful label — `name`, `details.parameter_size`, `details.quantization_level`, and `capabilities` (so models without `tools`/`vision` can be flagged or filtered):

```json
{
"name": "gemma4:12b",
"details": { "parameter_size": "11.9B", "quantization_level": "Q4_K_M" },
"capabilities": ["completion", "tools", "thinking", "vision"]
}
```

Suggested behavior:
- On Preferences open (or on Provider→Ollama selection), fetch `/api/tags` with a short timeout (~1s).
- On success, merge results with pi-ai's bundled list (de-dup by id), prefer the live list for labels.
- On failure (Ollama not running, network blocked), fall back silently to the current hardcoded list and surface a small hint like "Ollama not reachable on `localhost:11434` — showing built-in defaults."
- Optionally make the base URL configurable (`OLLAMA_HOST` env or a per-provider `baseUrl` field) so remote/non-default Ollama setups also work.

**Why this would help**
- Newly pulled models "just work" without a Loom release.
- Removes the maintenance burden of keeping pi-ai's Ollama list in sync with what people actually run locally.
- Capability flags from `/api/tags` let Orbit pre-warn about tools/vision support (one of the more confusing footguns with local models).

Related: #149 (Galaxy MCP architecture — separate issue, same general theme of "discover capabilities from the live system instead of bundling lists").

Read app/src/main/ipc-handlers.ts:506–552 and app/src/renderer/app.ts:2529–2552 to trace how Ollama models are listed and how custom entries are rendered. Start by checking the existing models:list-all flow, then verify the /api/tags response and its timeout and fallback behavior. Done means installed models appear in Preferences, bundled entries remain available, and unreachable Ollama falls back silently with a hint.

Written by the indexing model from the issue text.