[hardware] 🐛 Bar mask-op acceptance while vrgather/vcompress owns MaskB

[emiliengnr]

Hello, here is a pull request for a bug I found.

Problem

A mask-producing compare that keeps its destination (use_vd_op), e.g. vmslt or
vmsleu, reads its old vd through the shared MaskB operand queue.
vrgather/vcompress also borrow MaskB through an ad-hoc path, and the block at the
end of the sequencer process rewrites operand_request[MaskB]/_push[MaskB]
unconditionally while vrgat_state_q == REQUESTING. A mask op accepted in that window
has its vd request silently overwritten, so the mask unit waits forever for an
operand nobody asked the register file for, and Ara wedges (only reset recovers).
VFU_None already guards against this; VFU_MaskUnit did not.

Stall-detector evidence (seed19633/seed12524): MSK=1, compare operands arrived
(aluv=11), vd never did (vdv=00), and the gather FSM is back to IDLE — the
request was lost, not delayed.

Fix

For a use_vd_op mask op, hold acceptance until the ad-hoc user releases the queue
(vrgat_state_q == IDLE), mirroring the existing VFU_None guard. Mask ops that do
not read vd push nothing on MaskB and are accepted freely.

Related / ordering

This guard waits for the gather/compress FSM to return to IDLE, which is guaranteed
by the vrgather-FSM safety exit in #469. Please review/merge this with #469: on its
own against current main the FSM can still stick (the bug #469 fixes), in which case
the guard waits on that pre-existing hang rather than introducing a new one. It is the
VFU_MaskUnit sibling of the VFU_None MaskB guard in #475.

Changelog

Fixed

• Fix deadlock when a mask op (vmslt/vmsleu) is issued while vrgather/vcompress owns MaskB

Checklist

• Automated tests pass
• Changelog updated
• Code style guideline is observed