feat(providers): add Zed agent provider

[iamtoruk]

Closes #480.

Adds a provider for Zed's built-in agent. Full credit to @chatzinikolakisk for documenting the on-disk format in the issue; the schema was additionally verified byte-for-byte against a real Zed install.

How it works

• Single source: threads.db (macOS ~/Library/Application Support/Zed/threads/threads.db, with Linux and Windows paths mapped). One row per thread; the data blob is zstd-compressed JSON.
• Each thread's request_token_usage map is emitted as one call per request with exact input/output/cache_creation/cache_read token fields (Anthropic semantics), priced through the existing LiteLLM engine, deduped as zed:<threadId>:<requestId>.
• In-progress threads with an empty per-request map fall back to cumulative_token_usage so they still count.
• Decompression uses Node's built-in zlib.zstdDecompressSync (no new dependency). It ships from Node 22.15; since the package floor is 22.13, the provider feature-detects and skips with a notice on older Nodes, mirroring the node:sqlite guard.
• Registered as a lazy provider like the other SQLite-backed ones, so --provider zed validates and non-Zed users load nothing extra.

Testing

• Six fixture tests build a real threads.db (exact schema) with zstd-compressed thread JSON: per-request emission with exact token fields, cumulative fallback, non-zstd and malformed-blob skipping, cross-parse dedup, zero-usage threads, and missing-DB discovery.
• Full suite passes (1,393 tests). CLI smoke against a real (empty) Zed install runs clean.

Known limits

• Per-request timestamps do not exist in the map, so all of a thread's calls carry the thread's updated_at; day-level attribution for long-running threads is approximate.
• The local install used for verification has an empty threads table, so numbers were validated via fixtures, not real history. @chatzinikolakisk, if you are up for it, running codeburn overview --provider zed on this branch against your real usage and posting the result would be a great validation.
• folder_paths is not yet mapped to per-project attribution; all Zed usage lands under a single zed project for now.

[iamtoruk]

Validated end-to-end against a real Zed thread now (fresh install, real agent chat): the provider's output matches the store token-for-token on all four fields (input 37,786 / output 3,594 / cacheRead 176,640 / cacheWrite 0). Two findings from the live data are folded in: the per-request map undercounts (cumulative was ~3x the map sum), so threads now top up to the exact cumulative counter with a remainder entry, and legacy uncompressed json rows are read alongside zstd. Format details additionally verified against Zed's source (crates/agent/src/db.rs: DataType, DbThread, TokenUsage, SerializedLanguageModel).