arm_v81m: calibrate Cortex-M55 memory model

[bremoran]

This PR is the model-calibration follow-up to #420, the Armv8.1-M instruction-support PR. It keeps the scope limited to Cortex-M55 memory instruction modeling and runner-integrated regression coverage needed by downstream ML-KEM/ML-DSA N657x0 SLOTHY generation.

Modeled instruction forms:

• ldrd <Rt0>, <Rt1>, [<Rn>, <imm>]
• ldrd <Rt0>, <Rt1>, [<Rn>]
• ldrd <Rt0>, <Rt1>, [<Rn>, <imm>]!
• ldrd <Rt0>, <Rt1>, [<Rn>], <imm>
• strd <Rt0>, <Rt1>, [<Rn>, <imm>]
• strd <Rt0>, <Rt1>, [<Rn>, <imm>]!
• strd <Rt0>, <Rt1>, [<Rn>], <imm>
• scalar str <Rt>, [<Rn>, <imm>]
• scalar same-base str <Rt>, [<Rn>, <imm>] -> ldr <Rt>, [<Rn>, <imm>] store-load hazard classification for same DTCM bank immediates

Source of model values:

• LDRD result latency is modeled as 2 cycles, matching the Arm Cortex-M55 Software Optimization Guide instruction timing table for scalar load results. The existing scalar LDR 2-cycle result latency remains unchanged.
• STR/STRD are modeled as single-issue store-pipe operations according to the Cortex-M55 Software Optimization Guide. Since stores have no GPR result, the 1-cycle latency entry is only the SLOTHY fallback when a store is queried as a producer; it is not intended to model a store-to-load forwarding latency.
• The same-bank scalar STR -> LDR rule is a conservative scheduling heuristic, not a measured scalar forwarding result. It is limited to same-base scalar immediate forms where both immediates are known, and it uses the Cortex-M55 DTCM bank derived from address bits [3:2]. The Cortex-M55 TRM documents four 32-bit DTCM interfaces, and the SWOG uses address bits [3:2] when describing same-bank TCM conflicts for MVE memory accesses.

Known approximation:

The scalar store-load hazard helper is intentionally narrow. It does not attempt full alias analysis, does not classify unknown immediates, and does not make a downstream performance claim beyond avoiding a risky nearby scalar same-bank STR -> LDR schedule. No scalar same-bank microbenchmark evidence is included in this PR.

st_ld_hazard_ignore_stack remains pseudo-stack-only: it suppresses virtual stack save/restore traffic identified by the existing stack instruction predicates. Scalar STR/LDR pairs with stack bases such as r13 or the target model's sp spelling are treated as physical memory accesses and still use the scalar same-bank heuristic.

Downstream impact:

This provides upstream model coverage for the memory forms needed by downstream mldsa-native/mlkem-native M55/N657x0 generation, especially generated Keccak and INTT variants using stack LDRD/STRD and scalar stack load/store scheduling. No downstream generated assembly or autogen changes are included.

Tests run:

• ../../venv/bin/black --check slothy/targets/arm_v81m/cortex_m55r1.py tests/naive/armv8m/_test.py tests/naive/armv8m/test_*memory*.py
• ../../venv/bin/flake8 slothy/targets/arm_v81m/cortex_m55r1.py tests/naive/armv8m/_test.py tests/naive/armv8m/test_*memory*.py
• ../../venv/bin/python -W error test.py --tests instruction_model_m55,memory_model_m55 --timeout 0
• ../../venv/bin/python -W error test.py --only-target=slothy.targets.arm_v81m.cortex_m55r1 --timeout 0

[mkannwischer]

Thanks @bremoran.

As far as I can tell this correctly models the memory-instruction timings and DTCM bank hazards, but I didn't run any experiments to confirm the values and trust @bremoran. We can always fine tune it later.
I don't think there is a high risk of this change introducing any regressions, so I'll go ahead and merge this.