fix: repoint the archiver tips cache before a write commits

[spalladino]

Split out from #25357.

The race

The archiver serves getL2Tips() from an in-memory cache (L2TipsCache) that is reloaded after each store write commits, while getProposedCheckpointData() reads the store directly. Between a write committing and the cache reload finishing, a concurrent reader can pair pre-commit cached tips with post-commit store reads. Concretely: a checkpoint promotion commits, a reader then sees the promotion gone from getProposedCheckpointData() but still-stale tips, and misclassifies the chain state — e.g. NodePublicCallsSimulator deriving next-block globals concludes the next block continues a checkpoint that is in fact already checkpointed, mis-pricing its fee.

#25357 adds reader-side detection (read tips, read the proposed checkpoint, re-read tips, retry on movement), which catches any write that moves the tips between the two halves — but both tips reads can land inside the commit-to-reload window and hit the same stale cache, so the reader-side check alone cannot close the race. This PR closes it from the writer side.

The fix

• L2TipsCache.refreshAfter(write) points the cache at write.then(reload) before the write commits. Registration happens synchronously in the same tick as transactionAsync, so the commit cannot beat it: any reader arriving after the write starts waits for post-commit state instead of being served pre-commit tips. If the write fails, the cache keeps the tips it had (nothing was committed).
• A rejected tips load (a failed post-commit reload, or a failed first load) is dropped from the cache after the failure surfaces, so the next read retries from the store — one transient failure cannot leave every subsequent getL2Tips() rejecting until the next write happens to come along.
• Every store mutation in ArchiverDataStoreUpdater goes through a single writeAndRefreshTips helper that wraps the transaction and awaits the write and the reload together (Promise.all), so a failed write cannot leave the reload dangling as an unhandled rejection. The plain post-commit refresh() is deleted (no callers left).
• Correctness relies on store writes committing in registration order, which holds because the LMDB store serializes write transactions through a single writer queue; this is now documented on the class.

Tests

• l2_tips_cache.test.ts: a reader arriving before the write resolves gets the post-commit tips; a failed write keeps the previous tips; a failed post-commit reload surfaces to the caller and the next read recovers; a failed first load recovers; chained refreshes end at the newest state, including when the first of two writes fails.
• data_store_updater.test.ts: parks a checkpoint promotion in the commit-to-return window and asserts a concurrent reader is served tips consistent with the store (the proposed-checkpoint frontier and the proposed tip describe the same chain).

Note

A-1897 tracks the deeper fix: one atomic getChainStatus() snapshot (tips + proposed checkpoint read in a single store transaction, cached in memory), which would make both the reader-side retry in #25357 and this writer-side mechanism unnecessary. If A-1897 lands soon, this PR can be dropped in its favor; until then this closes the live race.

[spalladino]

Closing: pointing the tips cache at the in-flight write makes every getL2Tips() reader block for the duration of any write, including large addCheckpoints batches during initial sync. That latency change is not acceptable for a hot read path. #25384 closes the same race with an atomic archiver snapshot instead, so this PR is superseded.