[hardware] 🐛 Raise illegal_insn for reserved VWXUNARY0 encodings

[emiliengnr]

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

Problem

Ara's VWXUNARY0 decoder tells the three defined sub-ops apart by the rs1 field:

case (insn.varith_type.rs1)
  5'b00000: ... // vmv.x.s
  5'b10000: ... // vcpop.m
  5'b10001: ... // vfirst.m
  default :;    // <-- reserved encodings absorbed silently
endcase

RVV 1.0 §16.1 marks any other rs1 value as reserved. Because the default arm does
nothing, the instruction still runs the rest of the OPMVV header with
ara_req_valid asserted and reaches the lanes as a malformed request (op
defaults to VADD, vfu = VFU_Alu). The lanes accept it but never produce the
scalar response, so the cva6 host stalls on the accelerator handshake until reset.
An unprivileged reserved encoding wedges the accelerator.

Fix

Raise illegal_insn in the default arm, as the spec requires. Valid code is
unaffected.

Related to the VWXUNARY0 handling in #467, but a distinct fix (that PR addresses
use_vs1; this one traps the reserved encodings).

Changelog

Fixed

• Raise illegal-instruction for reserved VWXUNARY0 sub-op encodings (were silently hanging)

Checklist

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