A single failed read drops the whole Hermes tab, because its cache replaces instead of merging #153

Also found while working on #141, and filed separately from the diagnostics issue because the blast radius is different — this one loses data the user can see, without any read being wrong.

In LocalAdditionalUsageCache, OpenCode and Cursor merge a fresh read into what they already had, and Hermes replaces:

case .opencode: return (LocalUsageReader.dedupKeepMax(existing + loaded), [:])          // :131
case .hermes:   return (LocalAdditionalUsageReader.hermesEntries(modifiedSince: since), [:])  // :133
case .cursor:   return (LocalUsageReader.dedupKeepMax(existing + loaded.entries), ...)  // :143

hermesEntries ends } ?? [] (:299), and that nil is the failure query returns for BUSY, a failed open, or a partial scan. So one unlucky read stores [] over a good cache, fetchDaily returns nil, and UsageStore.swift:553 only appends a snapshot if today != nil — the Hermes tab disappears and its tokens leave today's total until the next successful refresh, two minutes later at the default interval. Nothing is logged, so from the outside it reads as "I wasn't using Hermes".

OpenCode and Cursor do not have this, because existing survives a failed read. The asymmetry looks unintentional rather than deliberate: Hermes' read covers the whole window, so there is nothing a merge would break, and dedupKeepMax is keyed on the turn id.

Two ways to fix it — merge with existing like its two neighbours, or have hermesEntries distinguish failure from empty so the cache can keep the previous set. The second is what #151 does for Antigravity, and it composes with the diagnostics issue.