docs(cli): update README

Full Changelog: v0.6.2...v0.6.3

docs(cli): update README

Full Changelog: v0.6.1...v0.6.2

fix(cli): version string and per-project API key

Full Changelog: v0.6.0...v0.6.1

feat(cli): per-project API key override

Full Changelog: v0.5.1...v0.6.0

fix(cli): track turns count in Claude Code and Cursor scanners

Counts user-prompt turns per session in both scanners and sends them to the API, mirroring the turns field already tracked for CI runs.

feat(cli): harden secret file permissions, dedupe stale-session logic, and align with style guide

Security

• Restrict config.json, the launchd plist, and the systemd unit file to mode 0600 — they embed the API key in plaintext and were previously written at the default umask (world/group-readable on most systems)

Fixes

• Extract a single isStaleRunning() helper instead of two independently-drifting staleness checks in classifySessions and resolveVanishedSessions
• Remove a dead branch in the API client (session.tokens is never nullable)
• Reuse formatCost() in the watch loop instead of inlining cost formatting

Style

• Add explicit return types and JSDoc to the logger
• Convert positional multi-param functions to object params and alphabetize object fields per the project's TypeScript style guide

fix(sync): force-complete stale RUNNING sessions in classifySessions, not just vanished ones

Previously the 4-hour stale override only applied to sessions absent from the scanner. Sessions that the Cursor scanner still found as RUNNING (because its lastUpdatedAt gets refreshed on any UI access) were silently skipped as unchanged. Now classifySessions forces sessions to success when the scanner reports RUNNING but sync-state shows they've been running for >4 hours.

fix(api): treat 404 response as error instead of silent success

The API client was not handling 404 responses — they fell through to the success path and sync-state was incorrectly updated to reflect a successful submission even though the server rejected it (e.g. repo not found). This caused sessions to appear stuck as RUNNING on the server while sync-state believed they were already resolved.

fix(sync): force-complete RUNNING sessions stuck longer than 4 hours

The Cursor SQLite DB refreshes lastUpdatedAt on any UI access (not just new messages), so sessions would remain running indefinitely whenever a user opens them. Sessions that have been in sync-state as running for more than 4 hours are now force-completed to success on the next full sync, regardless of what the scanner reports.

fix(sync): resolve vanished RUNNING sessions even when engine is missing from sync-state

Sessions submitted before sync-state was extended to store engine were being skipped by resolveVanishedSessions due to a guard that required engine to be present. Now falls back to 'cursor' when engine is missing, so old stuck RUNNING sessions get resolved on the next full sync.