stats: cache_disabled is False even when no cache backend is configured

[ThomasWaldmann]

Store.stats always reports the cache_* keys, even when no cache backend is configured at all. In that case cache_disabled is False (and every other cache counter is 0), which reads as "there is a cache and it is enabled" — the opposite of the truth.

Seen from borg, whose stats output renders one line per stats key:

Store cache disabled: False
Store cache hits: 0
Store cache misses: 0
Store cache hit ratio: 0.0%
...

for a repo where BORG_STORE_CACHE was not set, i.e. borg passed no cache_url/cache_backend and Store.cache_backend is None.

Cause

_cache_disabled is a runtime kill-switch, not a "do we have a cache" flag:

• src/borgstore/store.py:124 — self._cache_disabled = False in __init__, unconditionally, regardless of whether a cache backend was given.
• src/borgstore/store.py:251 — it is only ever set to True when opening the cache backend fails at runtime.
• src/borgstore/store.py:334 — st["cache_disabled"] = self._cache_disabled, and lines 335-344 unconditionally add cache_hits, cache_misses, cache_hit_ratio, cache_errors, cache_{load,store,delete}_calls, cache_{load,store}_volume.

So "no cache configured" and "cache configured and working fine" are indistinguishable in the stats dict.

Suggested fix

Make the three states distinguishable, e.g.:

• Report cache_enabled = self.cache_backend is not None and not self._cache_disabled (positive phrasing avoids the double negative in rendered output), and/or
• only include the cache_* keys when self.cache_backend is not None, so consumers that render the dict generically drop the whole cache block for uncached stores.

Either way consumers (borg) would need a matching update to their key ordering / rendering. Happy to send a PR if you want to settle on which shape.