feat(integrations): add the Render adapter for deploys, service events, and bandwidth

Start with plan step 1: the issue is blocked until Render answers whether a DevMacro OAuth client with read-only access is possible, and Eddie decides the connection path — read the three comments before anything else. If unblocked, read docs/adapters.md ("Register the provider") and an existing adapter under src/lib/adapters/ next to types.ts and registry.ts, then build src/lib/adapters/render/ against sanitized fixtures. Done means deploys and bandwidth show on the dashboard, tokens refresh and revoke correctly, and e2e/render.spec.ts plus e2e/docs.spec.ts pass alongside npm run lint, typecheck, test.

Context

Requested by a potential user: Render (https://render.com) as a hosting platform, alongside Vercel, Railway, and DigitalOcean. Eddie wants it in the MVP (2026-11-14).

Research from Render's documentation and live endpoints, checked 2026-11-14:

Blocker for an OAuth-only MVP

The MVP connects providers through OAuth only (decision on #40). Render's OAuth server works, but DevMacro cannot get a client without Render registering one, and nothing documented says an OAuth grant can be read-only. Someone has to ask Render (partnerships or support) for a DevMacro OAuth client with read-only access. That request is Eddie's, because it speaks for DevMacro to a vendor.

If Render says no, the only read-only path is a scoped API key, which needs the API key connection path planned in #49. Choosing that for the MVP reverses part of the decision on #40, so it goes to Eddie as an options table on this issue.

Plan

1. Ask Render for an OAuth client with DevMacro's redirect URI, and ask whether a grant can be limited to read (services, deploys, monitoring). Record the answer on this issue. If the answer is no or read-only is not possible, post an options table (OAuth with full access, scoped API key through #49, or not in the MVP) and wait.
2. Adapter in src/lib/adapters/render/: authorize with PKCE, exchange and refresh tokens, revoke through /v1/oauth/token/revoke. External account: the workspace (GET /owners).
3. Sync: deploy events per service (deploy_succeeded and deploy_failed categories, so they count in the dashboard headline and the deployment streak in #304), service events such as server_failed and autoscaling, and bandwidth usage per service. No spend: Render exposes none, and the provider page says so.
4. Webhooks, per #28 and the decision on #424: deploy and service events by webhook with polling as the backfill. Through the setup panel in #426 the user chooses: automatic setup, an opt-in that asks for workspace write access and creates the webhook with POST /webhooks, with the panel's warning that Render has no read-only access that can create a webhook; or setup by hand in Render's dashboard (Integrations > Webhooks, workspace admins), pasting Render's signing secret back into DevMacro. Webhooks need the Pro plan or higher, and on Pro the workspace's one webhook URL may already be in use, so automatic setup checks first and the copy says so. If the OAuth client Render issues in step 1 is not read-only, the connection already holds write access, and the panel must not claim that setup by hand keeps DevMacro read-only.
5. Register the provider in every file listed in docs/adapters.md, "Register the provider".
6. Provider page docs/providers/render.md from the template in docs/adapters.md.

Acceptance criteria

• Render's answer on an OAuth client and read-only access recorded on this issue, and Eddie's choice if an options table was needed.
• A Render connection is made through the connection path Eddie chose, with what the grant allows shown on the connect screen.
• Deploys and service failures appear on the timeline, and successful deploys count in the dashboard headline.
• Bandwidth usage per service appears on the dashboard with its unit, period, and retrieved-at time. No spend figure is shown.
• Tokens refresh before expiry, disconnect revokes the token, and a revoked grant marks the connection as needing a reconnect.
• Tested against recorded, sanitized fixtures. No live provider calls in CI.
• Playwright e2e: e2e/render.spec.ts connects the simulated provider end to end, and e2e/docs.spec.ts covers the new provider page.

Files and areas

• src/lib/adapters/render/ (new), src/lib/adapters/types.ts, src/lib/adapters/registry.ts, and the rest of the "Register the provider" table in docs/adapters.md.
• docs/providers/render.md (new), docs/operations/oauth-apps.md, docs/operations/deploy.md.
• Non-goals: logs, Postgres and Key Value data, workflows, and anything that writes to the user's Render workspace other than the webhook the user opts into in step 4.

Verification

• npm run lint, npm run typecheck, npm test, npm run test:db
• npx playwright test e2e/render.spec.ts e2e/docs.spec.ts

Depends on

• Render issuing a DevMacro OAuth client (plan step 1)
• #28 Ingest provider webhooks, and #426 the webhook setup panel (webhook half only)
• #49 only if the API key path is chosen

Branch: <issue-number>-render-adapter
Closes with a Closes #<issue-number> footer on the commit or pull request.

Model: anthropic/claude-opus-5-5 | Reasoning effort: unknown