[BUG] `fcvt` instructions fail to update `mstatus.FS` to Dirty after implicit `fcsr` modification

Placeholder hjw_arch
2026-01-03T06:32:28Z

### Description
During floating-point verification, we observed that `fcvt` family instructions (e.g., `fcvt.lu.d`) fail to update the `mstatus.FS` field to `11` (Dirty) when they trigger a floating-point exception (e.g., overflow) that modifies the `fcsr` register.

While the `fcsr` register is correctly updated (flags are set), `mstatus.FS` incorrectly remains in its previous state (e.g., Clean `10`). According to the RISC-V Privileged Specification, any instruction that modifies the floating-point unit state, specifically including implicit writes to `fcsr` flags, must set the FS field to Dirty.

### Reproduction Code
The following assembly initializes `mstatus.FS` to Clean and then executes an `fcvt` instruction that causes an overflow:

```
.globl _start
.section .text.init
_start:
mepc_setup:
la x13, init
csrw 0x341, x13

init_env:
li x26, 0x0000000a0011fd88
csrw 0x300, x26
li x16, -1
csrw 0x3b0, x16
li x16, 0x1f
csrw 0x3a0, x16
mret

init:
fsrmi 0
csrr x5, mstatus
li x24, 0x0000000000004400 # Set FS to Clean (SD=0)
csrw mstatus, x24

# Setup data for overflow
li x5, 0x645c2763b01e0d7f
fmv.d.x f4, x5

j main

.section .text
.align 2
nop
.globl main
main:
csrr x2, fcsr
csrw fcsr, x0
csrrw s8, mstatus, s8 # Ensure Clean state

# This causes overflow, writes fcsr, SHOULD mark FS dirty
fcvt.lu.d s10, ft4

csrr x1, mstatus
csrr x2, fcsr

la t5, write_tohost
jr t5

.section .text.trap
.align 4
write_tohost:
la t1, tohost
li t2, 0x1
fence rw, rw
sw t2, 0(t1)
_exit:
j write_tohost
instr_end:
nop
.section .tohost, "aw", @progbits
.align 6
.global tohost
tohost:
.dword 0x0
.align 6
.global fromhost
fromhost:
.dword 0x0
```

### Observed vs Expected Behavior
After executing `fcvt.lu.d`:

- Spike (Reference): `mstatus` becomes `0x8000000a00006000 ` (FS=11, SD=1).
- CVA6 (RTL): `mstatus` remains `0x0000000a00004000 ` (FS=10, SD=0).

### Analysis
It appears the logic handling `mstatus.FS` updates misses the case where instructions targeting GPRs (like `fcvt`) implicitly modify the `fcsr` flags.

### Related Issue & Regression Analysis
We are aware of [Issue #2934](https://gitlab.eclipse.org/openhw-group/backup-20260329/cva6/-/issues/2934), which previously addressed logic errors regarding the correct setting of the `mstatus.FS` bit. While that issue improved the general FS update mechanism, our verification indicates that the specific scenario of `fcvt` instructions is still handled incorrectly. Unlike standard FP instructions, `fcvt` targets Integer Registers (GPR) while implicitly writing to `fcsr`. It appears the logic fixed in #2934 did not cover this specific path, or a regression has occurred.