[hw] Retire a reduction under its own id, not a stale result tag

[emiliengnr]

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

Problem

A vector reduction can hang the core with no trap. The response-emit block in spatz_vfu.sv:312
sets the completion id from result_tag:

vfu_rsp_o.id = result_tag.id;

result_tag is the tag of the last result that drained through the FU. On the normal path that is
the retiring instruction, but on the reduction_done path it is stale: the reduction runs for many
cycles after the last ordinary result drained, so result_tag still holds a prior op's tag. A
vredxor.vs running as id 1 emitted a response for id 0, so the controller cleared running_insn[0]
and left the reduction's own running_insn[1] set. issue_rsp_o.isfloat is the OR across
running_insn, so it stays high, Snitch stalls on the next fcsr access, and the core hangs.

Fix

On reduction_done take the id from spatz_req, which is the retiring reduction, and force a vector
response since a reduction writes the VRF and never a scalar rd:

vfu_rsp_o.id      = reduction_done ? spatz_req.id : result_tag.id;
vfu_rsp_o.wb      = result_tag.wb && !reduction_done;
vfu_rsp_o.result  = (result_tag.wb && !reduction_done) ? scalar_result : '0;

When reduction_done is 0 every ternary collapses to the original, so a non-reduction emit is
bit-identical.