fix: support millisecond quote stamps in simulations

[6heLL66]

Found this while testing Metric on staging. Titan quotes are for the next block, but we simulate them against the current block. Metric stores milliseconds in a different part of the storage word, so we miss it. This can cause FeedStalled() during simulation.
This adds the missing timestamp adjustment for Metric. The price data and existing seconds handling stay unchanged.
This format will be stable and will not change in the future.

Example:

This Metric word was captured from Titan for block 25925280:
0x5f3f82df171805f5e2f401018738ad0713148735fecc13140001a07bb2de3800
It contains the timestamp 1788781715000 ms. The simulation runs at the parent block, 25925279, whose timestamp is 1788781703000 ms — 12 seconds earlier.
The old code only recognizes seconds in the first four bytes. Metric stores milliseconds at offsets 25..31, so its timestamp is left unchanged and is in the future relative to the simulation.
With this fix, the word becomes:
0x5f3f82df171805f5e2f401018738ad0713148735fecc13140001a07bb2af5800

[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)?

[6heLL66]

I tried using the same stamp, but a newer Metric quote could stop seconds quotes from being adjusted. Keeping them separate avoids changing the existing behaviour.

[fleupold]

I still don't understand why we need a full BTreeMap for the Metric lane, where for other lanes a single stamp seems to be fine? Could you explain this to me with an example (you may assume I'm not particularly familiar with propAMM's implementation details).

[6heLL66]

Removed the map and the extra per-word checks, I added it as an extra check against restamping stale quotes. It isn’t required for Metric’s format, and the existing seconds path doesn’t have it either.

[fleupold]

I drafted #4911 that does't copy the stamp field and which gives more context to the reader on why this is needed. It passes the test you added, but would still ask @6heLL66 to verify this would also fix the issue and either update this PR or let me know so I can push the other one for review.

[6heLL66]

Thanks @fleupold, tested #4911 with our captured Titan data and the oracle call now passes. Looks good, please go ahead with your PR.