Add deterministic emulator timing and stage profiling

[Happymic]

What This PR Does

This PR makes emulator timing repeatable and auditable. It adds the core machinery we need before measuring MoE workloads: deterministic event ordering, cycle/byte attribution, and timing golden checks.

Concrete Changes

• Makes runtime event ordering deterministic so repeated runs produce the same timing.
• Adds cycle-level stage-profile fields, including resource/busy/wait-style accounting needed by later MoE timing reports.
• Adds HBM/Ramulator accounting hooks used to compare logical bytes with physical emulator traffic.
• Adds timing golden workloads and a checker that fails when cycles or HBM bytes drift.
• Extends emulator runner metadata so timing runs can be traced back to workload/build settings.

Why This Is Separate

This is the foundation PR for the timing stack. It does not introduce Qwen traces or representative experiments yet; it only makes the emulator timing path stable enough for those later PRs.

Validation

Ran locally:

nix develop -c bash -lc 'cd transactional_emulator && cargo build --release && cargo test --workspace --release'

export PLENA_ROOT=/path/to/plena
export PYTHONPATH="$PWD:$PWD/PLENA_Compiler:$PWD/PLENA_Tools:$PWD/transactional_emulator/testbench${PYTHONPATH:+:$PYTHONPATH}"
python3 transactional_emulator/testbench/timing_goldens/check_timing_goldens.py --plena-root "$PLENA_ROOT"

All timing goldens matched.

[qichao-arlo-wang]

Superseded by #97, which consolidates the MoE timing-replay stack (#93–#96) into a single branch against main with the review findings fixed. Closing in favor of #97 (CI green).