Extend additional scan folders to every provider, not just Claude #177

Every provider resolves its log location on its own, and only Claude can be pointed somewhere else from inside the app. #162 adds a settings field for extra Claude scan folders; this issue tracks extending that to the rest.

Where each provider looks today

Environment overrides are now read through the login shell (#176), so they work from a GUI-launched .app. What remains is that four providers have no override at all, and that an environment variable is an awkward thing to ask a menu bar app's user for.

Why this is worth doing

The failure mode is silent. A relocated log directory does not produce an error — the total is just lower than it should be, and nothing in the UI suggests a folder was missed. #144 removed this for Claude's known locations, #162 removes it for arbitrary Claude locations, and the same hole stays open everywhere else.

No user report for a non-Claude provider yet, which is why this is not urgent. It is also not evidence of absence: the whole point is that an affected user cannot tell.

Constraint: a folder must belong to a provider

The obvious shape — one flat list of folders that every reader tries — should not be used. Readers are not safely interchangeable on the same directory. LocalUsageReader.jsonlFiles already carries an allowJSON flag that exists specifically so the Gemini reader's .json handling does not pick up Claude's .meta.json; that hazard generalizes once arbitrary folders are fed to arbitrary parsers. Cross-parser contamination would show up as inflated or misattributed totals, which is harder to notice than the undercount this is meant to fix.

So each entry has to name its provider. Two workable shapes:

• one list per provider (settings keyed by provider id), or
• one list with a provider tag per entry.

The first fits the existing extension convention better — CONTRIBUTING.md already says a usage source is added by implementing UsageProvider and registering it, so the natural hook is on that protocol, with each reader consulting its own configured roots.

Storage

#162 stores its value under a provider-scoped key so this work does not need a migration. Whatever shape is chosen here should keep that property.

Scope notes

• Root discovery differs per provider (recursive .jsonl walk vs. locating a SQLite file inside the directory). The unit is a directory in every case, so the setting can stay uniform; interpretation stays with each reader.
• normalizedRoots folding and hidden-directory skipping interact badly with user-supplied roots — see the discussion in Add user-configurable additional scan folders with wildcard support #162 before wiring a second provider through it.
• The settings UI should not grow one text field per provider. A provider picker plus a single list is likely the right presentation, but that is a design question, not a decision made here.