refactor(protocol)!: rename Update.block_number_or_timestamp to block_number

[die-herdplatte]

Last of four PRs replacing #1440 — Stack #1556 (#1554, #1555, #1561, #1562). One field is renamed; nothing else changes.

Why now, and not earlier

Update.block_number_or_timestamp was named for the two things it could hold. HeaderLike had two implementors: BlockHeader, which returns a block number, and the RFQ path's TimestampHeader, which returned a unix timestamp — it existed only because an off-chain book has no block and still had to travel through TychoStreamDecoder to reach a consumer.

That was honest while it lasted, and it cost a real bug downstream: a consumer that evicts simulation overlays by block number treated a venue's unix timestamp as one, and evicted everything.

#1561 deletes TimestampHeader with the round trip that needed it, leaving BlockHeader as the only implementor. Every Update on every path now carries a block number, so the field can say so. Doing this before the port would have renamed a field that was still carrying timestamps.

What changes

-pub block_number_or_timestamp: u64,
+pub block_number: u64,

37 reference sites across 10 files, all mechanical. HeaderLike::block_number_or_timestamp() in tycho-client keeps its name, and the two decoder call sites that read it with it: it is the accessor on the header trait, and the trait is what the follow-up below removes.

Breaking change

No serde alias. A serialized Update — a saved market recording — written under the old name fails to load with missing field block_number and needs the key renamed. An alias was considered and left out: it would keep a field name that no longer describes anything readable in the type forever, for the sake of recordings that #1561 already invalidates in other ways (every pair-keyed component id and every book state's serialized form changed there), so a recording that survives this rename does not replay anyway.

Follow-up, not here

With one implementor left, the header generic itself is dead weight: HeaderLike, FeedMessage<H> and StateSyncMessage<H> in tycho-client, and TychoStreamDecoder<H> and TryFromWithBlock<T, H> (23 implementations) in tycho-simulation, all exist so a TimestampHeader could stand in for a block header. Removing the parameter is mechanical but breaks the public API of both crates, so it is its own PR.

Verification

• cargo clippy --workspace --all-targets --all-features clean, cargo +nightly fmt --all --check clean.
• block_number_or_timestamp survives only as HeaderLike's accessor in tycho-client and the two decoder call sites that read it.
• tycho-simulation --lib: 1668 pass, the 17 failures the RPC_URL-gated EVM tests that fail on main too; tycho-integration-test 34 pass; tycho-execution 198 pass with its 4 RPC_URL-gated failures.

🤖 Generated with Claude Code