Lower HUGR to QIS with Selene's compiler at the Python boundary and retire PECOS's compile entry points

[ciaranra]

Phase 2 of moving HUGR handling to the Python boundary (the interpreter removal was #732/#733).

Why

PECOS carried its own copy of the HUGR-to-QIS compiler and used it at runtime through the pecos-rslib-llvm wheel, plus three more Python compile entry points (one shelling out to an external hugr-llvm binary) and a broken keyword on the pipeline function. HUGR is upstream's format; the compiler should be upstream's too.

What changes

• One boundary, pecos_rslib.hugr_lowering.compile_hugr_to_qis(hugr_bytes, *, platform="helios", opt_level=2, emit_debug=False), lowers with Selene's selene_hugr_qis_compiler and then applies PECOS's helper-symbol pass to the LLVM IR text: the four PECOS runtime helpers that Guppy declares (pecos_qis_trace_metadata_hugr, pecos_qis_trace_metadata_qubit_hugr, pecos_qis_runtime_barrier_qubit_hugr, pecos_qis_runtime_barrier_qubits2_hugr) are renamed from their private __hugr__... forms at every use, duplicate declarations of the same LLVM type are merged, conflicting or wrong-ABI declarations and any definition of a helper fail loudly, strings and comments are left alone. pecos.compilation_pipeline.compile_hugr_to_qis re-exports it.
• The QIS route (pecos_rslib sim()) imports that module at runtime instead of the LLVM wheel. The bindings wheel declares the compiler under an optional hugr extra; quantum-pecos depends on it directly (selene-hugr-qis-compiler~=0.4.2).
• Removed: the shell-out HugrLlvmCompiler, the private GuppyFrontend/run_guppy_on_pecos/compile_guppy_to_qir frontend (dead: used only by its own tests and one example, and already calling a nonexistent method), HugrTypeError (keyed on a message only the old compiler produced, nothing raised or caught it), and the fallback chain in _compilation. pecos.execute_llvm and pecos.engines.compile_hugr_to_qis delegate to the boundary; get_compilation_backends reports the Selene compiler.
• The Rust crate pecos-hugr-qis and the LLVM wheel's compile export stay for the Rust facade until the next phase; the parity test keeps comparing the two.

Behaviour

Running a Guppy program is unchanged: the two compilers share tket-qsystem's lowering, and a d=3 surface-code program with trace metadata and barriers produces byte-identical hosted-operation traces through either (pinned by a new test that runs both on the QIS route and compares capture_qis_operation_trace). Differences in the emitted text (target triple, EntryPoint attribute, malloc naming, expanded borrow checks) are inert. Invalid HUGR bytes now raise the compiler's HugrReadError instead of a RuntimeError from the Rust binding; a missing compiler package raises ImportError naming selene-hugr-qis-compiler.

Verification

tests/guppy/test_helper_symbols.py (rename on the observed Selene form, merges, conflicts, wrong ABI, define, strings, comments, quoted identifiers, CRLF), tests/guppy/test_compilation_boundary.py, python/pecos-rslib/tests/test_hugr_lowering.py; the migrated lowering tests; full guppy, pecos, qec lanes 5,197 passed; optional lane 23; Selene and SLR 461; bindings 2,300; doc tests 309; pre-commit, cargo fmt, cargo clippy -p pecos-rslib -D warnings clean. Independent adversarial review executed 25 hand-crafted IR cases against the pass and verified the DEM-path traces.

Closes #407 for the runtime path.