lsu: don't substitute FP store data for the walker's PTE write

[davidharrishmc]

The FP store-data mux in the LSU sits after the walker's PTE write-data mux and was selected by FpLoadStoreM alone, so with menvcfg.ADUE=1 an A/D-update walk started by an FP store or load (or by an instruction fetch while fclass, fmv.x.* or an FP load/store was in M) wrote the FP register into the PTE: fsd to a D=0 page left f1's bits in the PTE instead of the PTE with D set. The TLB was filled correctly, so the corrupt PTE took effect only after eviction or SFENCE.VMA, letting user data become a leaf PTE. The same happened on F-only configs with XLEN=64 (f_rv64gc, fh_rv64gc), where the FLEN < XLEN branch of the mux was used. hptw.sv now muxes FpLoadStoreM with the walker (fpmux, next to rwmux and the other M-stage controls it overrides), and the LSU uses the resulting LSUFpLoadStoreM for both store-data mux branches, the bus size and subwordread, so no FP control reaches the walker's access. It adds the fpADUpdate test (fsd/fld, rv64gc) and fpADUpdate32 (fsw/flw) in a new coverage64f suite that f_rv64gc and fh_rv64gc run in the nightly regression; the suite is self-checked, unlike coverage64gc. Part of #1921.

🤖 Generated with Claude Code

[rosethompson]

While this change is functionally correct, it is inconsistent with the style established with the existing control signals gated by SelHPTW. All other M stage control signals are brought into hptw.sv and muxed with the hptw's driver. For example...
mux2 #(2) rwmux(MemRWM, HPTWRW, SelHPTW, PreLSURWM);
This should be updated to match the same style.