fix(cli): force exit after render to prevent process hang

[miguel-heygen]

Summary

• Adds process.exit(0) after render completes in the CLI render command
• Fixes the process hanging indefinitely after npx hyperframes render --output video.mp4
• Root cause: Node.js fetch() keep-alive pool (from update checks and telemetry) keeps TCP connections open, preventing the event loop from draining
• Telemetry is preserved — the exit handler in cli.ts calls flushSync() which spawns a detached child process

Test plan

• Run npx hyperframes render --output test.mp4 and verify the process exits after completion
• Verify telemetry events are still sent (check PostHog)

[jrusso1020]

The diagnosis is correct — Node.js fetch() (undici) keeps TCP sockets alive in a connection pool, which holds the event loop open and prevents the process from exiting.

However, process.exit(0) is a band-aid. The root cause is that our two fetch() call sites don't close their connections:

1. updateCheck.ts — fetch(NPM_REGISTRY_URL, ...) fires at startup
2. telemetry/client.ts — fetch(POSTHOG_HOST/batch/, ...) fires on flush

Adding Connection: "close" to both fetch calls tells undici not to pool the socket, so it closes after the response completes. With that fix, the event loop drains naturally after render:

// updateCheck.ts
const res = await fetch(NPM_REGISTRY_URL, {
  signal: controller.signal,
  headers: { Connection: "close" },
});

// telemetry/client.ts
await fetch(`${POSTHOG_HOST}/batch/`, {
  method: "POST",
  headers: { "Content-Type": "application/json", Connection: "close" },
  body: JSON.stringify({ api_key: POSTHOG_API_KEY, batch }),
  signal: controller.signal,
});

With this, the flow becomes:

1. Update check fetch runs → Connection: close → socket closes after response
2. Render completes → event loop drains → beforeExit fires
3. Telemetry flush() runs → also Connection: close → socket closes
4. Event loop drains → process exits cleanly

No process.exit(0) needed, and the flushSync() detached-process fallback in the exit handler stays as a safety net for process.exit(1) calls in error paths.