feat: detect & reuse already-running local services during Install

[evereq]

Description

Add automatic detection of already-running local services (Ollama, Open WebUI, SearXNG, Qdrant, etc.) during Dream Server installation. When a service is detected, the installer prompts the user to reuse it instead of deploying a duplicate. Choices are persisted in .env and Docker Compose profiles skip containers for externally-provided services. Dependent services are automatically rewired to connect to the external instance.

Use Case

Many users already have parts of the AI stack running locally before they install Dream Server — Ollama is the most common example. Today the installer ignores these and deploys its own copies, which leads to:

• Wasted resources — duplicate containers competing for the same GPU and RAM
• Port conflicts — installer tries to bind ports already in use, causing silent failures
• Unnecessary downloads — multi-GB model files re-downloaded when the user already has them loaded in their running Ollama
• Poor first-run experience — users expect the installer to be smart enough to detect and integrate with their existing setup rather than fighting it

Proposed Solution

A new installer phase (03-service-scan) that runs after hardware detection and before service deployment:

1. Scan — reads each service manifest for its default port and health endpoint, then probes localhost:{port}{health} with a 2-second HTTP timeout
2. Prompt — for each detected service, asks: "Use existing instance instead of deploying Dream Server's own? [y/N]"
3. Record — writes EXTERNAL_{SERVICE_ID}_URL=http://localhost:{port} to .env
4. Skip — Docker Compose uses per-service profiles; external services simply aren't activated. Model downloads are skipped when the external service is the LLM.
5. Rewire — dependent services get the external URL injected via existing env vars (e.g., LLM_API_URL for Open WebUI → Ollama)

The feature is fully reversible: remove the EXTERNAL_* env var and restart to switch back to Dream Server's managed instance. In non-interactive/CI mode, the scan runs in log-only mode and users can pre-set EXTERNAL_* vars.

Seven of the 19 services are candidates for detection: llama-server, Open WebUI, SearXNG, n8n, Qdrant, Whisper, and TTS. Dream Server-specific services (dashboard, dashboard-api) are always managed.

Full spec with architecture diagrams, edge cases, schema changes, and implementation order will be attached (but just as a quickly generated Drafts, require review!)

Alternatives Considered

1. Pure environment variable approach (no Compose profiles) — same detection, but instead of profiles, dynamically filter services out of the docker compose up command. Rejected because Docker Compose doesn't natively support "skip this service" — you'd need to generate partial compose files or use docker compose up service1 service2 ... with an explicit service list, which is fragile and breaks when extensions add new services.

2. Generated override file (docker-compose.external.yml) — detection phase writes an override file that sets scale: 0 for skipped services. Rejected because scale: 0 combined with depends_on healthchecks causes dependent services to hang waiting for a container that will never start. Also harder to debug than profiles.

3. Detect-only with manual config — scan and report what's running, then tell the user to edit .env themselves. Rejected because it creates friction and defeats the purpose of a "single command" installer. Users who want manual control can still set EXTERNAL_* vars directly.

[evereq]

existing-service-detection.md