VersionTracker produces incorrect version chains from cache

[robyngit]

VersionTracker builds obsolescence chains from SysMeta and stores them in the browser using localforage plus an in-memory cache. It tries to persist full version information for every PID in the chain to speed up retrieval and avoid repeated DataONE API calls. In practice, storing the entire chain per PID is redundant and error-prone. When a new version is found, every record in the chain needs to be updated to reflect the new predecessor/successor relationships. Using two forms of storage (in-memory + localforage) adds complexity and increases the chance of inconsistency.

In testing, I'm seeing intermittent incorrect chains (e.g., missing versions). This suggests cached records are not being updated reliably when new versions are found or added. There also may be a concurrency issue where multiple writes to IndexedDB (via localforage) can overwrite each other, leading to partial or lost data.

These version storage issues could be the underlying cause of #2750.

A cleaner approach is to remove the in-memory cache and rely solely on localforage. The stored information persists across reloads and can be shared across tabs. Reads from IndexDB are fast enough for this purpose. We should also only store the immediate predecessor and successor for each PID instead of persisting the full chain. That keeps each record authoritative. The full chain can be reconstructed on the fly when needed.

Since this storage logic needs to handle concurrent writes, TTL/expiration, and general consistency, it makes sense to split it into a dedicated storage class rather than keeping it inside VersionTracker.