[Bug Report] Architectural state updates for REM/REMUW instructions are misattributed to incorrect PCs in trace logs

### Description

Hello, we found that, in Rocket Core, `REM/REMUW` are executed asynchronously by the divider unit. We have identified an issue in the trace logging mechanism where the side effects (register writeback) of these instructions are not correctly associated with their originating Program Counter (PC).

While these instructions retire in-order, the logger prints a placeholder (0xXXXXXXXXXXXXXXXX) at the time of retirement. However, when the asynchronous operation finally completes, the result is printed on the log line of whatever instruction happens to be retiring at that cycle. This creates a causality violation in the trace, making it appear as though an unrelated instruction modified the register.

### Evidence

The following trace snippet demonstrates the misattribution during a REMUW operation:

**1. The initiating REMUW instruction (PC: 0x800002ce):**
```plaintext
3 0x000800002ce (0x02d9783b) x16 p16 0xXXXXXXXXXXXXXXXX
```
The result for `x16` is unknown at this point because the divider is busy.

**2. The incorrect attribution at a later PC (0x800002ec):**
```plaintext
3 0x000800002ec (0x00143807) x16 0x0000000000000000
```
At PC `0x2ec` (which is actually an `fld` instruction), the log incorrectly reports that `x16` was updated to `0`.

**Impact:**
- Trace Ambiguity: It is impossible to reconstruct a precise architectural state from the logs, especially when traps or exceptions occur between the issue and completion of a REM instruction.
- Verification Complexity: Verification teams must implement complex workarounds to "guess" which previous instruction a delayed writeback belongs to.

### Minimal Assembly Code for Reproducing

```assembly
li x18, 0x0
li x13, 0x17
li x16, 0x1dc52a8a
remuw x16, x18, x13
fcvt.d.l f14, x19, rtz
csrrs x19, fflags, x0
fcvt.s.lu f14, x18, rup
csrrs x13, fflags, x0
li x8, 2415919033
fld f16, 1(x8)
```

### Attachment File

We have attached program.dump, program.elf, trace log, program.S in [program.zip](https://github.com/user-attachments/files/24414262/program.zip) for reproducing.

Start by reproducing the issue with the attached program.S, program.elf, program.dump, and trace log, focusing on the REMUW sequence and the later fld retirement. Trace the divider writeback and logger inputs to determine where the originating PC is lost. Done means the delayed register update is reported on the REMUW instruction's PC rather than a later instruction's log line.

Written by the indexing model from the issue text.