docs: clarify blockstore cache sizing and flatfs sharding (#11303)

* docs(config): clarify BlockKeyCacheSize and BloomFilterSize BlockKeyCacheSize was documented as "size in bytes" but the underlying boxo blockstore wires it directly to lru.New2Q[K,V](size int) which is an entry count, not a byte budget. Fix the unit and add memory sizing guidance (~200 B/entry) plus what the cache actually short-circuits (per-block flatfs Stat on the bitswap server hot path). BloomFilterSize section expanded with: what the filter answers (negative Has only), saturation behavior at runtime growth, startup AllKeysChan rebuild cost (one-time, scales with keyset not data volume), and a cross-link to BlockKeyCacheSize as the complementary positive-path cache. Drop the dead go-ipfs-blockstore link. * docs(datastores): explain flatfs next-to-last/3 for large blockstores The default next-to-last/2 shard depth (~1024 dirs) becomes a per-shard file-count problem on nodes growing past a few million blocks: bulk enumeration (GC, BloomFilterSize rebuild on startup, Provide.Strategy=all reprovider) and per-block Stat both pay readdir cost proportional to files-per-shard. next-to-last/3 (~32k dirs) keeps per-directory counts in a range modern filesystems handle well and is the recommended choice for pinning clusters, public gateways, and mirrors. Note that shard depth is fixed at ipfs init time and re-sharding requires a full export/import. * docs(config): expand BloomFilterSize sizing with bbloom specifics Replace the generic worked example with a power-of-two reference table covering 10M to 500M blocks, and document two kubo-specific behaviors that the generic bloom-filter math does not capture: - ipfs/bbloom rounds the bit count up to the next power of two, so non-power-of-two BloomFilterSize values silently allocate more memory than configured (e.g. the historical 1199120-byte example actually allocates a 2 MiB internal filter). - kubo wires bbloom with k=7 hash positions; the FPR formula is fixed at (1 - exp(-7n/m))^7. Memory cost is roughly ~1.2 B/entry at ~1% FPR and scales linearly with target FPR. Add a saturation section showing FPR degradation at 2x / 4x / 8x the design n (~11% / ~58% / >95% respectively), and a Risks subsection clarifying that a poorly sized filter is an operational waste rather than a correctness issue (no false negatives), with a quick bytes-per-block health check. Update the hur.st calculator URL from the n=1e6 default (dev-laptop scale) to n=10e6 (representative of real kubo deployments). Reference sizes verified empirically against ipfs/bbloom v0.1.0: a 16 MiB filter at n=10M gave 0.1875% observed FPR vs 0.18% predicted; the historical ~1.14 MiB worked example at n=1M gave 0.0545% vs 0.054% predicted at the rounded 2 MiB allocation. * docs(config): define FPR up front in BloomFilterSize section The BloomFilterSize section uses "FPR" throughout without defining it. Explain in the intro that the false-positive rate is the probability of a "maybe present" answer for a CID that is not actually in the blockstore, that a false positive costs at most one wasted datastore lookup (no data loss or incorrect retrieval), and that lower FPR means more inbound Has() calls answered from RAM alone. * docs: fold rounding penalty into bloom filter budget byte/entry sizing figures now report the operationally-useful number after bbloom's power-of-two rounding, so an operator following the guidance lands close to the true memory footprint instead of the raw design-point size. - config.md (BloomFilterSize): bump byte/entry to ~1.8/2.8/4.2 at ~1% / 0.1% / 0.01% FPR, state the average ~1.5x rounding penalty (worst case ~2x); drop 500M / 1 GiB row whose m/n=17.18 broke the uniform 10.74 ratio of the rest of the table; active-voice and comma fixes in saturation, risks, and startup prose - config.md (BlockKeyCacheSize): split a comma splice; active voice in 2Q replacement description - datastores.md (flatfs): align shard table columns; soften reshard wording to note kubo ships no in-place tool, not that flatfs forbids it