Stop re-reading the whole xite tree at startup

[MudDev]

A node holding a large xite was unusable for tens of minutes after every
restart. Not slow to sync - every app page hung on its loading screen,
because dbQuery did not return at all.

What was happening

set_edx_store takes the global xite_activation_gate for write and
holds it while it registers every served xite. dbQuery needs that same
gate for read, via recheck_db_query_receipt, on every iteration of
its retry loop. So for as long as registration runs, every dbQuery on
every xite blocks - the retry budget never even starts counting, because
the await is on the lock.

Registration read the tree twice:

1. revalidate on every extern object. The only cheap check was the file
   length; everything else was a full BLAKE3 re-read of every byte.
2. register_entry calls ObjId::of_file on every declared file,
   hashing it end to end purely to rediscover an id the manifest already
   states - and only then adopting it, which on any boot after the first
   is a no-op.

Measured on a node with a 232 GB xite: 411 GB read in the 25 minutes
after a restart, with siteInfo answering in 3 ms and bad_files: 0
the whole time while dbQuery had not returned after 240 seconds. A
gateway with 18 small xites finishes registration in seconds and looks
perfectly healthy, which is what makes this easy to misread as an
application bug.

The fix

Pass 1 - record the (len, mtime) a file had when its bytes last
verified, in a new local extern_stamp table, and skip the re-read while
both still match. Absent, malformed or different falls back to the full
check, so this trades a re-read for a stat, never verification for
trust. Every write to the extern mapping clears the stamp, so a relocated
or retired object can never be judged by a stamp describing another file;
only a completed verification writes one back.

Pass 2 - is_extern_at asks the store whether an id is already
adopted, complete, and backed by exactly this path. Registration uses it
to skip the rediscovery hash. Anything less - different path, incomplete,
not an extern, outside the xite root - answers false and falls through to
the original hash-and-adopt. A file that genuinely changed is still
caught, because revalidate retires it before this point.

The extern_stamp table is local like extern itself: never signed,
never transmitted, safe to discard.

Result on the affected node

	time	read
before	34m 22s	497 GB
after	1m 53s	1.54 GB

Same 3515 objects from 23 xites registered either way. dbQuery now
answers in 1-16 ms during startup instead of blocking, and the page
that hung on six loading skeletons renders identically to the gateway.

The first boot after upgrading still does one full pass, because no
stamps exist yet; it records them as it goes.

Tests

Two new ones. revalidate_skips_rereading_an_unchanged_extern corrupts
the bytes but restores the mtime - answering "complete" is only possible
without reading - then moves only the mtime and asserts it is rejected.
is_extern_at_answers_only_for_the_exact_adopted_file covers the wrong
path, an unknown object, and a path outside the xite root.

Also drops a never_loop in epix-reticulum/tests/mesh.rs that failed
cargo clippy --all-targets (deny-by-default) while the build passed.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud