Description
Currently every container that needs NATS connectivity must be configured with the explicit NATS URL (e.g. `nats://nimsforest.nimsforest.com:4222`) either via env vars or config files. This creates fragile config that breaks when containers are rebuilt or moved between environments.
**Proposed**: A container should only need to know which forest it belongs to — something like `forest: nimsforest.mynimsforest.com` — and derive the NATS URL, webhook URL, and other connection details from that single identifier. This could work via:
1. A well-known DNS pattern (e.g. `nats.nimsforest.mynimsforest.com` resolves to the NATS endpoint)
2. A discovery endpoint (e.g. `GET https://nimsforest.mynimsforest.com/.well-known/forest` returns `{"nats_url": "...", "webhook_url": "..."}`)
3. Land injecting a single `FOREST` env var and the nim SDK resolving everything from it
This would make containers portable across forests and eliminate the current pattern where every service has to hardcode infrastructure URLs in its config.
**Currently affected**: nimsforestissue, nimsforestwebchat, nimsforestodoo, agentclaudecode, nimsforestwebviewer — all have `NATS_URL` or equivalent hardcoded.
Nebula's reasoning: This is a solid infrastructure improvement that reduces config fragility across 5+ services. Medium priority because it's not blocking any deployments today — services work fine with hardcoded URLs — but it's the kind of foundational work that compounds in value as more nims are added to forests. Title, description, category, and project were all already well-defined.