feat: vihaco circuit component backed by ppvm simulators

[david-pl]

Context

To integrate with the stellarscope virtualization platform, ppvm needs a vihaco component that executes quantum circuit instructions by delegating to ppvm's simulation backends (Pauli Propagation runtime or Generalized Tableau).

A stub already exists in stellarscope at crates/stellarscope-circuit: it defines 15 gate instruction variants (X, Y, Z, H, S, T, RX/Y/Z, RXX/YY/ZZ, CNOT, CZ, U3) but has no operands (no qubit indices or rotation angles) and a no-op execute that only logs. This issue is about building the real implementation in ppvm on top of it.

Prerequisite: QuEraComputing/stellarscope#51 (generic component macro support) must be merged first, since the ppvm circuit component will be generic over the simulation backend.

Work items

1. Complete the instruction set in stellarscope-circuit

The current instructions have no operands. They need to carry:

• Qubit indices (one or two per gate)
• Rotation angles for parametric gates (RX, RY, RZ, RXX, RYY, RZZ, U3)
• Noise channel instructions: Depolarize1, Depolarize2, PauliChannel1, PauliChannel2, XError, YError, ZError (matching what the STIM parser already handles in feat: in-house STIM text format parser and FLAIR pipeline integration #44)
• Measure with a qubit index and a result-slot identifier

These additions should land in stellarscope, not ppvm — the stellarscope ISA is the shared contract.

2. Implement the ppvm circuit component

Add a new crate (e.g. ppvm-circuit or as part of ppvm-vm) that:

• Implements the vihaco #[component] macro on a struct generic over the simulation backend
• execute dispatches each instruction to the backend: Clifford + noise goes to the PP runtime or Tableau
• Measurement results are emitted as vihaco events so the machine can observe them

3. Define a minimal test machine

A simple machine (CPU + CircuitComponent) for integration testing, similar to stellarscope-demo. This does not need to be the production machine — its purpose is to verify the component can be wired into a vihaco machine and round-trip circuit execution correctly.

Why this unblocks mixed-mode BFS/DFS (see #40)

Once circuits run through the vihaco VM, the VM execution model is the natural interface for multi-threaded DFS Pauli propagation:

• Each DFS path is a separate VM instance with its own simulation state
• Multi-threaded DFS = spawning one VM thread per path, each running the same circuit bytecode independently
• The BFS front-end decides when to branch; branches hand off a cloned VM state to a new thread

Without the circuit component, DFS multi-threading has no VM execution to parallelize.