[BUG] `sb x3, 0(x2)` mis-traps when followed by `hlvx.hu x20, 0(x2)` after PMP CSR reads

Is there an existing CVA6 bug for this?

I have searched the existing bug issues

Bug Description

Summary

Trigger condition: A store byte (sb x3, 0(x2)) immediately followed by hlvx.hu x20, 0(x2) after a burst of CSR reads that touch mseccfg, pmpcfg*, and pmpaddr*.
Symptom: CVA6 raises LD_ACCESS_FAULT on the sb x3, 0(x2). Spike and Rocket both complete the instruction without traps.
Regression scope: The store behaves normally when either the CSR read is removed or the following hlvx.hu is removed. The anomalous behaviour only appears when both conditions are satisfied.

scenario-by-scenario behaviour

Scenario	Instruction skeleton	CVA6 `sb x3, 0(x2)` outcome
`verify_1`	`li x2, 0x8fffffdc` → `li x3, 0` → `sb x3, 0(x2)`	Store succeeds
`verify_2`	`li x2, …` → `li x3, 0` → `sb x3, 0(x2)` → `hlvx.hu x20, 0(x2)`	Store succeeds
`verify_3`	`csrr x19, mseccfg/pmpcfg/pmpaddr` × 11 → `li` setup → `sb x3, 0(x2)` → `hlvx.hu x20, 0(x2)`	`sb` trap with `LD_ACCESS_FAULT`

Test sequence (verify_3):

csrr x19, mseccfg
csrr x19, pmpcfg0
csrr x19, pmpcfg2
csrr x19, pmpaddr0
csrr x19, pmpaddr1
csrr x19, pmpaddr2
csrr x19, pmpaddr3
csrr x19, pmpaddr4
csrr x19, pmpaddr5
csrr x19, pmpaddr6
csrr x19, pmpaddr7
li   x2, 0x8fffffdc
li   x3, 0x0
sb   x3, 0(x2)
hlvx.hu x20, 0(x2)

Expected vs. actual behaviour

Expected (per Spike / Rocket store result): sb writes the byte at 0x8fffffdc to zero without any exception.
Actual (CVA6): sb is mis-reported as a load access fault;