fix(fetch): retire terminal requests before redirects

[murdoa]

Description

This came up during River/ZedBoard bring-up while debugging instruction fetch faults around supervisor trap handling. The fetcher left its memory
request enabled after consuming a terminal response, until the instruction was delivered.

That extra cycle could allow the MMU to accept a duplicate request. If the original fetch caused a trap, the duplicate walk could survive the
redirect and return a stale fault against the supervisor handler.

This changes the fetcher to withdraw the request on the same edge that consumes a terminal response, covering:

• Successful single-beat fetches.
• Page faults on the first beat.
• Successful completion of a straddling instruction.
• Page faults on the second beat.

Requests remain enabled when starting the second beat of a straddling instruction or retrying a transient invalid response. Those aren't terminal
completions.

Testing

Added 12 regressions covering RV32/RV64, single-beat and straddling instructions, successful responses, page faults and retries.

The tests check that the request is withdrawn immediately on completion, stays withdrawn while the result is held, and that fetching resumes
correctly after a redirect without retaining the previous fault.

All 12 new regressions fail against upstream 584f13a because the request remains enabled after completion. With the fix, all 66 focused fetch
tests pass:

  dart test \
    packages/river_hdl/test/core/fetcher_test.dart \
    packages/river_hdl/test/core/prefetch_fetcher_test.dart \
    packages/river_hdl/test/core/pipelined_fetcher_test.dart \
    packages/river_hdl/test/core/compressed_fetch_buffer_test.dart \
    packages/river_hdl/test/core/fetch_completion_test.dart \
    -r expanded