fix(api): eliminate N×Coolify calls on site list and startup sync

[rdemeritt]

Problem

GET /api/sites was calling listDeployments() for every app (N extra Coolify calls per request). The startup sync was calling getApplication() per dockercompose app redundantly — listApplications() already returns the same data. Combined, these exceeded Coolify's 200 req/min rate limit during dev restarts, causing 429 → 500/502 on the sites page.

Root cause timeline

This worked fine for months because the rate limit was never hit under normal usage (infrequent restarts, few sites). Today's rapid successive API rebuilds (PRs #113–#115) combined with user activity tipped past the threshold for the first time.

Changes

• api/src/routes/sites.ts — GET /api/sites drops listDeployments() per app; passes [] for deployments on the list view. GET /api/sites/:slug (single-site detail) is unchanged and still returns full deployment history.
• api/src/index.ts — startup sync drops getApplication() per dockercompose app; uses the app object from listApplications() directly. provisionTraefikRouteForCompose already handles missing docker_compose_raw internally via its own polling loop.

API contract impact

• GET /api/sites — deploys field is now always []. Consumers needing deployment history must use GET /api/sites/:slug.
• No other fields affected.

QA results (7/7 pass)

• Sites list returns 200 after fix ✅
• deploys: [] on list, full history on detail ✅
• Env vars endpoint no longer rate-limited ✅
• 3× rapid restart stress test — no 429 errors ✅
• All services healthy ✅