[dma] Clearing error code by writing to the status.error field seems to be one cycle delayed?

Nobody has claimed this yet.

### Description

Our team has seen some weird behaviour with the error code not being cleared when the status.error field has a 1 written to it.

In this test, an error was caused intentionally and the status.error bit was written to clear it.
Looking at the RTL at [line 1415](https://github.com/lowRISC/opentitan/blob/bb630faffe46d03c7f056e3d294b42a538528477/hw/ip/dma/rtl/dma_reg_top.sv#L1415) of the dma_reg_top module, we can see our write from the _status_we_, _status_error_wd_ and _status_flds_we[3]_ signal being 1. Then _reg2hw.status.error.q_ is cleared to one following the RW1C behaviour.
On [line 1324](https://github.com/lowRISC/opentitan/blob/bb630faffe46d03c7f056e3d294b42a538528477/hw/ip/dma/rtl/dma_reg_top.sv#L1324), _status_flds_we[3]_ is flopped before becoming _reg2hw.status.error.qe_ (red arrow).

When it comes to clearing the error code on [line 1321](https://github.com/lowRISC/opentitan/blob/bb630faffe46d03c7f056e3d294b42a538528477/hw/ip/dma/rtl/dma.sv#L1323) in the dma, it looks for (_reg2hw.status.error.qe_ & _reg2hw.status.error.q_) to clear the error codes. But _reg2hw.status.error.q_ was already cleared to 0 from the register write. So, we get qe being 1 but q as 0, causing the error codes to not clear.

Is there something that we are missing?

Start by inspecting hw/ip/dma/rtl/dma_reg_top.sv around lines 1324 and 1415, then hw/ip/dma/rtl/dma.sv around line 1323. Reproduce the described RW1C write and follow status.error.q, status.error.qe, and the DMA error-clearing condition across cycles; done means determining whether the apparent delay is expected or identifies a DMA RTL bug.

Written by the indexing model from the issue text.