Bump SIDECAR_CACHE_MAX_ENTRIES from 10k → 100k to reduce /sidecar/blob 404 floor

Review docker-compose.yml line 72, Dockerfile line 106, and nostr-pinner/instant_pin_cache.py line 657 to confirm the three default-value paths. Update the defaults to 100000 while preserving the environment-variable override, then run the provided curl and jq cache-stats check. Done means max_entries reports 100000 and the miss rate can be compared with the stated baseline.

Summary

Live measurement on the `unicity-ipfs1.dyndns.org` kubo container on 2026-05-29 showed the sidecar's instant-pin cache at 9,995 of 10,000 entries while only consuming 90 MB of its 1 GiB byte budget. The entry-count cap is the binding constraint, evicting recently-submitted blobs that wallets later try to fetch — producing ~33,405 `GET /sidecar/blob?cid=… 404` responses per 6 hours observed in container logs. Cache hit rate is only 3.3 %.

Proposed change

Bump `SIDECAR_CACHE_MAX_ENTRIES` from `10_000` to `100_000`. Memory budget remains adequate: ~9 KB average per cached entry × 100 k entries = ~900 MB, well within the existing 1 GiB `SIDECAR_CACHE_MAX_BYTES` cap.

Where it's set

• `docker-compose.yml` line 72: `SIDECAR_CACHE_MAX_ENTRIES=${SIDECAR_CACHE_MAX_ENTRIES:-10000}`
• `Dockerfile` line 106: `SIDECAR_CACHE_MAX_ENTRIES="10000"`
• `nostr-pinner/instant_pin_cache.py:657`: `max_entries=int(os.getenv("SIDECAR_CACHE_MAX_ENTRIES", str(DEFAULT_MAX_ENTRIES)))`

Default is fine to bump in all three places; the env-var override path (compose / run-ipfs.sh) is unchanged.

Verification

Before/after:
```bash
curl -s https://unicity-ipfs1.dyndns.org/sidecar/cache-stats | jq '{confirmed: .confirmed_entries, max: .max_entries, bytes_used: .bytes_used_total, bytes_max: .max_bytes, miss_rate: (.cache_misses / (.cache_hits + .cache_misses))}'
```

Expected: `max_entries` rises to 100000; `miss_rate` drops from ~0.97 toward the byte-budget limit.

Context

This is one of three distinct problems contributing to the wallet page freeze investigated 2026-05-29. The other two are wallet-side:

1. Deprecated `IpfsStorageProvider` chain-break retry loop — fixed in `unicity-sphere/sphere#326`
2. Sidecar's blocking DHT fallback returning 500 on timeout — separate issue, possibly tracked under the kubo DHT-provider tuning
3. This issue — the 4xx floor in the browser console that scares operators even when nothing's actually wrong

Disk free on the host is currently 501 GB so disk pressure is not a constraint. The kubo container itself is healthy (`Up 4 days (healthy)`, all live probes `200`).