RVV JIT support

[jserv]

Tracking issue for incremental JIT support of the RISC-V V Vector extension.

Current state

After PR #733 landed the interpreter implementation, V opcodes are marked translatable=0 in src/decode.h and have assert(NULL) stubs in src/rv32_jit.c (generated by reusing src/rv32_v_constopt.c's name list). Any block containing a V instruction therefore falls back to the interpreter; the JIT never executes V code.

Why this is non-trivial

JIT codegen for V is infrastructure-heavy: vector register state (rv->V[][]) has no existing JIT path, vector loops cannot be statically unrolled at translate time (vl is runtime-determined), and the cross-EEW / EMUL register-validation predicates need native equivalents.

Suggested phase 1

Pick a tightly-scoped starter set that proves the codegen contract end to end:

• vsetvli / vsetivli / vsetvl — vector configuration; gates the rest.
• vle{8,16,32}.v / vse{8,16,32}.v — unit-stride load/store.
• vadd.v{v,x,i} — proves the integer ALU pattern.

Each starter op also needs translatable=1 in src/decode.h and matching liveness wiring.

Out of scope for this tracker

• Tier-2 (T2C) support for V. File a separate issue once tier-1 phase-1 lands and proves the per-instruction codegen contract.
• Mask-producing ops, fixed-point, FP, segmented memory, permutations — file as follow-up phases once the starter set lands.

Tracked under the umbrella issue #504.