fix: support millisecond quote stamps in simulations

[6heLL66]

Description

Titan quotes can contain uint48 millisecond timestamps at bytes 25..31, as in the captured Metric quote below. The stream currently recognizes only leading uint32 seconds, so these quotes retain the builder's future timestamp and can revert when simulated at the parent block.

Recognize the millisecond layout by an exact match to its frame's projected timestamp, independently of oracle or venue addresses. Each format selects its newest timestamp separately: a newer millisecond quote cannot change which seconds quotes are restamped. The original seconds recognition, maximum selection and restamping body are preserved.

Track millisecond eligibility per winning account, slot and storage field, so overwritten or unrecognized frames cannot borrow freshness. Seconds-format matches retain priority, including dual-format words that later become stale. Millisecond timestamps are never moved forward; all other bytes and account fields are preserved. Both state and stateDiff are supported, with no public API or configuration changes.

For the captured quote targeting block 25,925,280, simulating at its parent changes 01a07bb2de38 (1788781715000 ms) to 01a07bb2af58 (1788781703000 ms). The remaining 26 bytes stay identical.

Follow-up to #4691.

Validation

No new tests are included in the final diff. Existing test fixtures and calls only receive the metadata/signature adjustments required by the implementation.

• Linux CI passed using production source identical to PR commit 1cb2f81e3, with four additional regressions kept in the validation branch: 23 simulator tests passed, 8 external-service/replay tests skipped. Clippy passed for all simulator features and targets with -D warnings (existing unreachable-Alloy-path configuration warnings remain).
• Regression checks fail before the respective fixes: missing millisecond support on the original implementation, and the clock-isolation case on the preceding shared-clock version. Both pass with the final code.
• Local checks passed 60,000 legacy-only comparisons, 46,080 mixed-format comparisons, and 144,000 outputs across 24,000 successive venue replacements. The mixed-input checks compare the original seconds selector and protected words against the exact base implementation on identical input histories, plus an independent reference for separate clocks and winning-word provenance. They also cover both clock orderings, millisecond-only snapshots, stale dual-format words, and integer boundaries. These checks use std-only substitutes for Alloy containers and remain outside the PR.
• Nightly formatting and independent correctness and standards reviews passed. The original seconds selection and restamping body were also compared byte-for-byte with the base.

The skipped external-service/replay tests remain unverified; the in-process websocket/reconnect test passed in CI.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[6heLL66]

I have read the CLA Document and I hereby sign the CLA

[fleupold]

Thank you for your contribution!

Can you please rework the PR description to give a bit more background knowledge for people with less context on the matter (please don't AI generate).

Is the stamp format documented somewhere and expected to be stable or will other issues like this come up in the future?

Also, I feel a concrete example + test of the current limitation and proof of the fix is missing to give us confidence in accepting this change.

[fleupold]

Why do we need a new type here? Can we not capture stamp in the existing type (but use the Metric specific encoding for detection)?