Fix VFU: Use ELEN instead of vsew for scalar/reduction operations

[luca24balboni]

Problem Description
The instruction vmv.x.s (vector-to-scalar move) caused a deadlock when executed with RVD=0 configuration (ELEN=32). The system would hang indefinitely waiting for result that would never arrive.

Root Cause
The bug was in spatz_vfu.sv, which used logic based on vsew to determine byte-enable masks for scalar operations. Scalar registers always have width ELEN (32 bits when RVD=0, 64 bits when RVD=1). vsew describes vector element size (8/16/32/64 bits), but vmv.x.s transfers an entire scalar register (ELEN bits), not a vector element (vsew bits).

Deadlock Mechanism
With RVD=0 (ELEN=32):

1. The vmv.x.s instruction is decoded with vsew=EW_8
2. VFU expects pending_results = 8'hff (8 bytes, based on wrong vsew check)
3. IPU produces result_valid = 4'hf (4 bytes, limited by ELEN=32)
4. Result ready check: &(result_valid | ~pending_results) = &(4'hf | ~8'hff) = &(0b11110000_1111) = 0
5. Deadlock: Bits 4-7 never become valid → instruction never completes

The bug didn't manifest with RVD=1 (ELEN=64) because the IPU produces 8 bytes, coincidentally matching the incorrect expectation.

[DiyouS]

Looks good to me, will rerun the CI after the server get fixed and merged the PR