Fix runtime guard, SQLite diagnostics, and Antigravity Windows discovery

[ozymandiashh]

Closes #250.
Closes #249.
Closes #232.

Summary

This PR fixes three recent runtime/provider failures that all presented as either silent zero-usage output or a crash before CodeBurn could explain what was wrong.

What changed

Node runtime guard (#232)

CodeBurn now starts through a tiny src/cli.ts launcher that checks for Node >=22.13.0 before dynamically importing the main CLI bundle.

That matters because Node 18 can currently install/run the package despite the engine mismatch, then crashes inside modern terminal dependencies with SyntaxError: Invalid regular expression flags. Early Node 22 also exposes node:sqlite inconsistently. The launcher keeps dist/cli.js small enough to parse on older Node versions and prints an actionable upgrade message before loading Ink/React/SQLite-backed provider code.

Packaging changes:

• Moved the existing CLI implementation to src/main.ts.
• Added src/node-runtime.ts with tested version parsing and guard messaging.
• Updated tsup to emit both dist/cli.js and dist/main.js.
• Kept target: node20 intentionally so the launcher can run far enough on older Node to print the upgrade message.
• Raised engines.node and README requirements to >=22.13.0.

Verified build shape:

• dist/cli.js is 1.46 KB and only contains the runtime guard + dynamic import.
• dist/main.js contains the full CLI bundle.

SQLite-backed provider diagnostics (#250)

Cursor, Goose, and OpenCode now check whether their DB data exists before checking SQLite availability. If data exists but node:sqlite cannot load, CodeBurn writes a clear stderr diagnostic instead of silently returning zero sessions.

This avoids the confusing Node 22.5-22.12 failure mode where OpenCode/Cursor usage exists on disk, but node:sqlite is gated behind --experimental-sqlite and the provider quietly reports nothing.

Also updated stale README text that still mentioned better-sqlite3; CodeBurn now documents the built-in node:sqlite requirement.

Antigravity Windows discovery (#249)

Antigravity provider discovery now handles the Windows language-server shape reported in #249:

• Process discovery uses PowerShell / Get-CimInstance Win32_Process on Windows instead of POSIX ps.
• Server flag parsing supports both legacy and Windows names:
  • --https_server_port
  • --csrf_token
  • --extension_server_port
  • --extension_server_csrf_token
• Flag parsing supports both --flag value and --flag=value syntax.
• CSRF-like values are sanity-checked so unrelated process lines do not become false-positive servers.
• Connect-RPC response parsing accepts both wrapped and unwrapped payload shapes for model maps and trajectory metadata.

Review fixes applied before PR

External review called out a few hardening points; this PR includes them:

• Added explicit CSRF token shape/length validation for Antigravity process parsing.
• Reduced Windows PowerShell discovery timeout from 8s to 5s.
• Forced PowerShell stdout to UTF-8.
• Guarded model-map extraction against malformed RPC payload entries.
• Added a Copilot legacy fixture for malformed assistant events while tightening TypeScript around that file.
• Added a tsup comment documenting why the launcher target intentionally remains below the runtime floor.

Tests

• npx tsc --noEmit
• npx vitest run tests/providers/antigravity.test.ts tests/providers/copilot.test.ts tests/node-runtime.test.ts
• npm run build
• npx vitest run — 40 files, 539 tests passed
• node dist/cli.js --version
• git diff --check

Pre-push review

• Argus-style local review: PASS
• Claude Opus 4.7 review: PASS after hardening follow-ups were applied
• Gemini 3.1 Pro Preview review: PASS; CLI emitted one model-capacity retry warning before returning the verdict

What it does NOT touch

• Token aggregation and pricing math
• Dashboard rendering
• JSON stdout payload shape
• Provider discovery paths outside Cursor/Goose/OpenCode/Antigravity runtime checks