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

`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.