Rule execution engine for lanekeep.

Discovery, gates, parsing, query matching and handler invocation, run over a corpus.

Why this is not in lanekeep-core

Architecture §3 places the walker in lanekeep-core. That does not work: running rules requires the sandbox, and the sandbox is built on core — putting the walker there would make lanekeep-core and lanekeep-js mutually dependent.

It cannot live in lanekeep-cli either, because lanekeep-testkit has to run rules too, and a test harness that reached into the binary crate would be a worse coupling than this one. So the walker sits above the sandbox and below both consumers.

Core keeps what it always had: the types, discovery, gates, and the ordering contract.

The shape of a run

discover paths (sorted)
  └─> for each file, in parallel:
        path gates ──reject──> skip without reading
        read bytes
        content gates ──reject──> skip without parsing
        parse once, shared by every rule targeting the file
        for each admitted rule: match its query, invoke the handler per match
  └─> sort violations

One parse per file, not per rule. Parsing is the dominant cost, and a file with twenty applicable rules must not pay it twenty times.