### wai-quantum 0.6.0: the HIP, npu-cores, tensor-engine and avx512 members, the dataflow device's vector engine, and the gate as a portable tensor program

Breaking in three places (the last bullet). The default features, `full`, and every pinned
digest are unchanged.

- **The HIP member** (`quantum_fabric_hip`, opt-in, Linux): the CUDA member's kernel text,
  unchanged, compiled at run time by HIP's runtime compiler for each device's own
  architecture, with contraction off. The runtime and its compiler are loaded when first
  used; the device's properties are read in the runtime's frozen layout, or the device is
  refused. Its own implementation id (`hip-lanes64/…`), its own key (`gpu-hip-<arch>`); the
  mutants are the CUDA kernel's. With `quantum_sv`, the dense f64 state vector runs the CUDA
  kernels' text too (`hip-sv64/…`).
- **The npu-cores member** (`quantum_fabric_npu_cores`, opt-in, Linux): the gate's
  arithmetic on one compute core of a neural processor's tile array, programmed directly
  rather than through a model runtime. The core forms each gathered pair's four rows in
  exact 64-bit integers; the host checks their range and keeps the low 32 bits. The program
  (`npu_cores.cc` in `npu_cores_design.py`) is built at run time with the tile array's open
  toolchain and cached per variant, generation and toolchain; the host side
  (`npu_cores_host.cpp`) is compiled against the device runtime and loaded. One program
  serves every gate and the arithmetic probe; each mutant is its own program. Key
  `npu-cores-<pci vendor>-<device>`.
- **The tensor-engine member** (`quantum_fabric_tensor_engine`, opt-in): the gate's sixteen
  products per pair as exact limb convolutions in one bf16 matrix multiply per tile of pairs,
  accumulated in fp32, on a tensor processor's matrix engine. Each value is four 8-bit limbs,
  which bf16 holds exactly; every limb product is at most `2^16` and every coefficient a sum of
  at most four, so fp32 holds every partial sum exactly in any order, on any engine that
  multiplies bf16 and accumulates in fp32. The host checks each coefficient is an integer
  below `2^24`, assembles the products and does the rest. The kernel runs as a helper under
  the engine's kernel toolchain; its target here is that toolchain's simulator, and every
  certificate says so. One mutant is nine-bit limbs, which the engine's inputs cannot hold.
- **The avx512 vector unit** (`quantum_fabric_vector`): eight 64-bit lanes, each `fx` an
  exact 32×32 multiply, an add and the unit's own 64-bit arithmetic shift. Discovery opens
  one member per instruction set the processor reports, so a processor with both units has
  both members.
- **Measured** on an integrated GPU (gfx1151), a neural processor's tile array and the
  processor beside them, all silicon: the HIP member 9/9 (66020 probe pairs, all four pinned
  certificates, circuits to 22 qubits, 6 of 6 mutants) and its state vector 3/3 (the pin
  `b7d129d0…`, 4 of 4 mutants); the npu-cores member 9/9 (66020 probe pairs, all four
  certificates, circuits to 20 qubits, 3 of 3 mutants); avx2 and avx512 9/9 each; the
  tensor-engine member on its simulator 9/9 (66020 probe pairs, all four certificates, 4 of 4
  mutants); and,
  unchanged, the WebGPU member (`gpu-vulkan-1002`) and the OpenCL member
  (`opencl-gpu-1002`, the state vector's pin included) bit-exact there. CI runs each of them
  on that host.

- **The vector engine as a member** (`quantum_fabric_dataflow`, key `dataflow-1e52-b140-vector`):
  on the device generation whose vector engine multiplies 23-bit numbers, the gate's
  arithmetic runs on that engine, 32 lanes at a time, on 32 compute tiles. Each tile's
  first core configures the unpacker and the packer and hands the tile its instructions
  inline; the unpacker copies the pairs' columns into the destination registers as
  32-bit integers, the vector engine forms the rows, the packer copies them back. Each
  32×32 product comes from four 23-bit partial products, corrected for sign; `fx` is
  held as 30 low bits and the rest, and each row's terms are added or subtracted with a
  carry after each. A pass is sized to its share of the pairs, in steps of 64.
- **`quantum_fabric::tensix`**: the compute tile's instructions the programs use, their
  opcodes and fields as the device simulator's own table gives them; CI checks the
  transcription against that table. **`quantum_fabric::vector_engine`** builds the
  programs, the probe included; the assembler check covers them too.
- **Measured** on the device simulator, built from source: 66020 probe pairs agree, all
  four pinned certificates, circuits up to 20 qubits match native, 3 of 3 kernel mutants
  (the same three the other members carry) killed. Every certificate is labelled
  simulator.
- **The gate as a portable tensor program** (`quantum_fabric::stablehlo`): the gate's rows
  and the arithmetic probe as a StableHLO module, the input of compilers for tensor
  processors, GPUs and CPUs. Every value is a 64-bit integer that never overflows
  (`|e·a| < 2^62`; a row of four `fx` stays below `2^35`), so a compiler must give the
  exact rows whatever it does with them. It is not a member: the program leaves the
  crate, a compiler's runtime runs it, and its outputs are compared with the exact ones. The
  `stablehlo_gate` example writes the module, its three mutants (the same three), a
  batch of 4096 pairs whose gate and states reach the 32-bit edges, and the outputs a
  build must give.
- **Measured** with two independent open-source tensor compilers, IREE 3.12.0 and XLA
  (through JAX 0.11.2, the compiler tensor processors take this program through): exact
  on the x86-64 CPU with each; on every Vulkan device of the hardware host (a discrete
  GPU, an integrated GPU, and a software one); on the discrete GPU through CUDA with
  each; through Metal on two generations of the macOS platform's GPU; with XLA on the
  arm64 CPU. On the CPU each mutant fails where it should under each compiler; on every
  other device, the third mutant's rows do. Builds for three GPU
  generations the fleet lacks compile but are not run. `ci/tensor-program/check.sh`
  holds each run to its outcome and fails a run that ends without stating one, so a
  device that cannot run reads as a failure, never as a mutant caught. CI:
  `wai-quantum-tensor-program`. That host's GPU runs it through HIP, built for the GPU's own
  architecture, and on both of its Vulkan devices.
- **The products on a matrix unit, as a portable program** (`stablehlo::limb_module`): the
  tensor-engine member's limb layout as one StableHLO `dot_general` of bf16 operands
  accumulated in f32, the program a compiler maps to a matrix unit. With it, the example writes
  a nine-bit-limb data set whose exact coefficients bf16 cannot reproduce, so a run that
  matches them is not comparing. Exact under both compilers on the x86-64 and arm64 CPUs and
  on the discrete GPU through CUDA. Not exact through one compiler's HIP build for the
  integrated GPU, whose bf16 multiply returns values that are not integers; CI shows that
  step and does not require it.
- **Breaking:**
  - an OpenCL key is `opencl-<kind>-<vendor id>`, the device's `CL_DEVICE_VENDOR_ID` in hex
    (`opencl-cpu-8086`, `opencl-gpu-10de`, `opencl-gpu-1027f00`, `opencl-gpu-1002`), not a word
    of the vendor's name; `opencl::DeviceIdentity` gains `vendor_id`, which the member id
    binds, and `vendor_slug` is gone;
  - `quantum_fabric_vector::Isa` gains `Avx512` (`Isa::ALL` has four), and `native_isas` lists
    every set written for the architecture;
  - `quantum_fabric_dataflow::Chip` gains `vector`.

