port-to-rustlisted

# Port to Rust ## A port is a behaviour-preserving move, and nothing else The one rule this skill exists to enforce: during a port, behaviour changes and code improvements are separate commits, separate reviews, and preferably separate weeks. A port that also fixes bugs cannot be validated — every difference is ambiguous between the fix and the regression, and the differential harness reports both identically. Improvements are written down as a follow-up list and shipped after parity is proven. ## Start from the parity contract, not from the code Before any Rust is written, the contract answers four questions: what the unit of parity is (a CLI invocation, a library function, an HTTP response, a file artifact); which differences are acceptable (log wording, timing, map iteration order, float formatting); which are not (any observable output a caller can branch on); and how parity is measured — the full form in `PARITY-CONTRACT.md`. A port without a written contract does not have a definition of done, so it finishes when someone gets tired. ## Five phases, in order | Phase | Ends when | |---|---| | 1. Inventory and seam | The boundary the Rust will live behind is named, and the call sites crossing it are counted | | 2. Characterize | The existing behaviour is captured as executable tests — against the source implementation, not the intended one | | 3. Port leaf-first | The lowest-dependency module is in Rust, called through the seam, with both implementations still presen