refactor(storage): remove the unused legacy Usage session scanner

[me2seeks]

Context

Desktop Usage now reads canonical data through the selected Runtime Host. The legacy Storage path remains in SettingsStore, but repository-wide production-call-site inspection finds no consumer outside its own definition and dedicated tests.

Scope

• Remove SettingsStore.usageStats and its readUsageStats import.
• Remove packages/storage/src/usage-stats-store.ts.
• Remove dedicated legacy-reader tests and stale public-entrypoint expectations.
• Verify repository-wide references, package entrypoints, Storage tests, Desktop tests, typecheck, and dependency analysis.

Non-goals

• Removing SettingsStore itself.
• Removing projectDesktopUsageStats; it still projects Host Session IDs into Desktop namespaces.
• Changing Runtime Host Usage, provenance, pricing, or UI behavior.
• Changing the Runtime Host wire contract or compatibility epoch.

Acceptance

• No production or test reference remains to the legacy scanner.
• Desktop Usage continues to use the selected Runtime Host.
• Storage and Desktop focused validation remains green.

Related

• Usage hides model attempts without token data and marks interrupted tools as successful #2128 tracks Usage coverage/presentation.
• fix(desktop): read Usage from Runtime Host #2641 is the superseded broad implementation branch.

[heeoneie]

I'd like to take this one.

I verified the premise before starting:

• The only importer of usage-stats-store.js is settings-store.ts:32.
• Desktop's settings:usageStats IPC handler resolves through loadUsageStats(deps.client, ...) in runtime-host-usage-ipc-main.ts — the Runtime Host client, not SettingsStore. The single .usageStats( call site in the repository is window.maka.settings.usageStats(range, host) at settings-surface.tsx:636, which goes through that same Host path.
• @maka/core/usage-stats/* is a separate module and stays untouched.
• usage-stats-store is not in packages/storage's exports map, so removing it is not a public-API change.

One thing worth flagging up front, since it is the "stale public-entrypoint expectations" part of the scope: usage-stats-store.ts imports createSqliteSessionMetadataStore, and that import is the only reason ./settings-store reaches node:sqlite. With the scanner gone, public-entrypoints.test.ts fails on only the declared entrypoints load node:sqlite until './settings-store' is dropped from SQLITE_BACKED_ENTRYPOINTS. So this change also takes @maka/storage/settings-store off the package's SQLite boundary — the direction #1257 argued for. I'll update that list in the same change and say why, as its comment asks.

Local result so far: -696/+0 across four files. @maka/core and @maka/storage typecheck and build clean, and the Storage suite is 969 pass / 3 fail — unmodified main in the same container gives the same 3 failures (read-only and permission assertions that don't hold when the test process runs as root).

I can't build Desktop in my environment (Electron postinstall and one registry dependency are blocked), so the Desktop side is verified by reference inspection only. I'll state that explicitly in the PR rather than imply I ran it.