fix: make MemoryUsageRegister thread-safe for concurrent validations

[themightychris]

Summary

MemoryUsageRegister is a process-global singleton — a single static instance with an unsynchronized registry list — and ValidationRunner.run() calls clearRegistry() at the start of every run. When two validations run concurrently in the same JVM, they append to the same list and one run's clear() wipes the other's in-flight snapshots, so summary.memoryUsageRecords is corrupted. Validation notices are unaffected, since the NoticeContainer is per-run.

This is the bug described in #2168.

Fix

Thread-confine the register. Both @MemoryMonitor interception points — ValidationRunner.run and GtfsFeedLoader.loadAndValidate — execute on the thread that invokes run(), so giving each thread its own register isolates concurrent validations with no locking and no behavior change for the single-threaded CLI/desktop path.

private static final ThreadLocal<MemoryUsageRegister> INSTANCE =
    ThreadLocal.withInitial(MemoryUsageRegister::new);

public static MemoryUsageRegister getInstance() {
  return INSTANCE.get();
}

Test

MemoryUsageRegisterTest adds a barrier-driven interleaving that forces the exact corruption (thread B calls clearRegistry() after thread A has registered a snapshot). On the old singleton it fails with expected: A1,A2 but was: B1,A2; with the fix each thread sees only its own snapshots.

Validation against a real concurrent service

We exercised this against an HTTP validator service (a Spring wrapper around a shared ValidationRunner, as in MobilityData/gtfs-validator-api#1), running 8 concurrent validations of a ~3 MB / ~13k-trip feed:

• Before: the 8 runs reported 4 / 13 / 14 / 17 / 24 / 28 / 28 / 31 / 32 memoryUsageRecords (the single-run baseline is 4) — cross-contaminated.
• After: all 8 runs report exactly 4 records with no cross-run contamination; notices are identical across runs.

Resolves #2168.

[davidgamez]

LGTM!