ship: project dashboard pages + sidebar/chat overhaul + log tooling

Ships accumulated WIP that was sitting uncommitted:
- New (home) dashboard route pages: overview, code, data/tables, hosting,
  infrastructure, services, domains, integrations, agents, analytics, api,
  automations, billing, logs, market, marketing(+seo/social), product, security,
  storage, users, settings(app/auth).
- dashboard-sidebar, project-icon-rail, chat-panel updates; mcp + anatomy route
  changes; package.json/lock dependency bumps.
- Coolify log tooling (scripts/fetch-app-logs.mjs + fetch-app-logs-ssh.mjs) and
  ai-new-thread.md "Fetching Production Logs" section.

Excludes throwaway debug scripts and telemetry audit dumps (the latter contain
live credentials and must not be committed).

ai-new-thread.md

@@ -202,3 +202,59 @@ early-failures are silently swallowed (failure PATCHes omit the `x-agent-runner-
 
 **Earlier (still true):** `vibncode://` deep link scheme is registered in `src-tauri/Info.plist`; Rust clippy is
 treated as errors on commit.
+
+---
+
+## 7. Fetching Production Logs (Coolify apps)
+
+The Coolify dashboard (`https://coolify.vibnai.com/...`) is login-walled, so to read an app's logs
+programmatically use one of the two paths below. Both read credentials from `vibn-frontend/.env.local`
+(`COOLIFY_URL`, `COOLIFY_API_TOKEN`, and `COOLIFY_SSH_HOST` / `COOLIFY_SSH_PORT` / `COOLIFY_SSH_USER` /
+`COOLIFY_SSH_PRIVATE_KEY_B64`).
+
+**The `<appUuid>` is the last path segment of the Coolify app URL:**
+`.../application/y4cscsc8s08c8808go0448s0` -> appUuid = `y4cscsc8s08c8808go0448s0`.
+
+| App | appUuid | Build pack | Notes |
+|---|---|---|---|
+| `vibn-frontend` | `y4cscsc8s08c8808go0448s0` | dockerfile | Next.js, port 3000, fqdn vibnai.com |
+| `vibn-telemetry` | `hou4vy5mtyg5mrx3w4nl2lxv` | dockerfile | port 4000; usage data lives in its **DB**, not stdout |
+
+### Method A - Coolify REST API (simplest)
+`GET {COOLIFY_URL}/api/v1/applications/{uuid}/logs?lines=N` with `Authorization: Bearer {COOLIFY_API_TOKEN}`.
+Returns `{ logs: "..." }`. Works for dockerfile / nixpacks / static apps; returns **empty for `dockercompose`**
+(Coolify can't pick which service to tail). Helper script:
+```bash
+cd vibn-frontend
+node scripts/fetch-app-logs.mjs <appUuid> [lines]    # reads .env.local itself
+```
+
+### Method B - SSH + `docker logs` (full history, timestamps, date filter)
+Use when the REST endpoint returns little/nothing (compose apps, or quiet services). Connects to the host with
+the `ssh2` lib and runs `docker logs` against the app's container(s). Coolify names containers
+`{appUuid}-{hash}`; a zero-downtime deploy briefly leaves TWO containers (old draining + new). Helper script:
+```bash
+cd vibn-frontend
+# everything since the start of a UTC day (note: logs are UTC):
+node --env-file=.env.local scripts/fetch-app-logs-ssh.mjs <appUuid> 2026-06-12
+# last 500 lines, no date filter:
+node --env-file=.env.local scripts/fetch-app-logs-ssh.mjs <appUuid> "" 500
+# target a specific container during a rollout (substring match):
+node --env-file=.env.local scripts/fetch-app-logs-ssh.mjs <appUuid>-003647723804 2026-06-12
+```
+Under the hood (reusable one-off): `runOnCoolifyHost()` in `lib/coolify-ssh.ts`, or for the compose-aware
+unified fetcher, `getApplicationRuntimeLogs()` in `lib/coolify-logs.ts` (API first, SSH `docker logs` fallback).
+List an app's containers: `docker ps -a --filter name=<appUuid> --format '{{.Names}}\t{{.Status}}'`.
+
+### Important caveat - container logs are NOT "usage logs"
+Both the Next.js frontend (production server) and the telemetry service only emit **startup lines + explicit
+`console.error`** to stdout - they do NOT log per-request activity. So `docker logs` is the right tool for
+**deploy health and crashes/errors**, but for actual product **usage** you must query the data store:
+- **Telemetry / usage** is written to Postgres by `vibn-telemetry-service` (its own `DATABASE_URL`). The existing
+  extractors (`vibn-frontend/scripts/extract-live-telemetry.ts`, `extract-ui-telemetry.ts`) pull telemetry by
+  querying `fs_chat_threads` / `fs_chat_messages` via `DATABASE_URL` - copy their pattern for date-ranged usage.
+- **Runtime errors** at scale are captured by **Sentry** (auto-provisioned per project), not container stdout.
+
+### Verifying a deploy landed
+`GET /api/v1/applications/{uuid}` returns `status` (`running:healthy` when good). On a fresh deploy the new
+container shows `Up About a minute (healthy)` and the previous one disappears once draining completes.