[aaj3f]

This started as a test flake in the store-less stats cache, and looking at that cache's key turned up a production case it can't tell apart, so the PR does both.

The key. The planner's stats view is cached under the ledger id, the snapshot's t, the query t, the overlay's epoch and a few flags, and none of those name the index the stats came from. A ledger dropped and created again under its name, then indexed to the same t with different data, matches that key, and the Fluree instance's leaflet cache outlives the drop, so the recreated ledger gets planned with the dropped ledger's stats. That's not just a worse plan: those stats can license folding FILTER(?x = ?y) into a join on the term, and on the recreated ledger, where ex:a is 1 and ex:b is 1.0, the filter then returns no rows instead of one. it_stats_view_identity does exactly that.

A snapshot now carries the content id of the index root its stats, schema and annotation arena were decoded from (LedgerSnapshot::from_root(root_id, bytes); every load path already had the id in hand, so nothing is hashed), and the key folds it in. Two loads of one root agree, and a different root never does. A snapshot that has stats but no root id to name them, which only tests build, gets its view built rather than shared. The store-backed key keeps the overlay's epoch(), as before, and the store-less cache still adds the content version, as before.

I first tried keying by the index store's id, which works for the collision but is new on every load, and a historical read loads its store again on every call, so it was rebuilding the view on every query. I measured the root key against main on each lane that reloads, counting stats-view builds per 20 queries (5,000 subjects, index at t=2):

Lane	main	store id	root id
head, ledger cache	0	0	0
db_at_t below the index t	0	40	0
db_at_t at the index t	0	40	0
db_at_t above the index t (novelty replayed)	0	20	0
db() with no ledger cache, with and without novelty	0	20	0

So every lane that hits on main still hits. The key is also hashed field by field now instead of format!-ed into a String first, which makes the hit itself cheaper: 0.24× main's instructions per lookup (about 50 ns vs 160 ns, 2M lookups in a dev-fast build, 5 alternating rounds), with or without a store. Loading a 1.3 MB root is flat (instructions 1.0003× main), since the id is just carried along.

One thing I left alone: a replayed novelty keeps the old epoch-based term on the store-backed path, which is what lets the above-t lane hit, but it also means two divergent clones of one novelty at the same t would share a slot there, same as on main. I haven't found a path that reaches that. Giving a replayed novelty a deterministic content version, from the commit at its t and the index t, would let that key use the content version too, but it changes what that version promises to every other cache that keys on it, so it probably wants its own look rather than riding along here.

The flake. stats_cache::tests::storeless_stats_view_is_reused_at_the_same_content_version failed once in a full fluree-db-query lib run under load, with "an unchanged overlay must hit the cache, not rebuild", and passed alone. The store-less views live in one process-wide eight-slot LRU, lib tests run as threads of one process, and 14 of the 15 views a full lib run puts there come from stats_cache's own tests, which run side by side. Eight insertions between the reuse test's two calls evict its slot. Its sibling, storeless_stats_view_misses_when_content_version_diverges, has the quieter half: under the same interleaving it passes against a cache that ignores the content version.

The LRU is now a small type, StorelessStatsCache. cached_stats_view_for_db keeps its signature and owns the one process-wide instance, as before, and every test in the module builds through its own. A new test pins the LRU itself (eight views fit, a hit refreshes one, the ninth insertion displaces the least recently used). binary_range's an_empty_overlay_probe_leaves_the_translation_lru_alone had the same shape, so it now reads a record of its store's insertions that nothing evicts, rather than an eight-slot LRU that churn can empty.

Proof.

• it_stats_view_identity fails with stats_cache.rs as on main, and when the root id is left out of the key; it passes with the fix. Leaving the no-root-id check out fails stats_with_no_index_root_to_name_them_are_not_shared, and leaving the content version out of the store-less key fails the miss test.
• With the stats_cache module looped 16,000 times, 8 at once, main failed the reuse test 25 times; this branch fails it 0 times. With eight other views pushed into the process-wide cache between the two calls, main fails it 5/5 and this branch passes 5/5.
• The tests still catch what they're for: the reuse test fails with eight insertions into its own cache and with a cache that never hits, the miss test fails when a slot ignores the version, and the LRU test fails with nine slots or with a hit that doesn't refresh.