Split detection from transport behind a Backend trait

Wraith's detection model — provenance, W^X, stack-integrity, and the
exploitation-chain correlator — was interleaved with the ptrace reap loop
in tracer.rs, so the eBPF backend the README already names as the
near-zero-overhead production path had nowhere to attach.

Extract the transport-agnostic detection core into src/engine.rs:

- Engine owns the per-address-space cached memory map, the per-process
  live stats, the Detector, the run Summary, and the enforce-on-CRITICAL
  policy. It captures a neutral SyscallEntry register snapshot and, in
  inspect(), refreshes the map, runs detection, and returns the
  enforcement Action to carry out — without ever issuing a ptrace call.
- Backend is the trait a transport implements (drive()). Tracer becomes
  the first Backend: it keeps only what is ptrace-specific — the waitpid
  loop, register reads, thread entry/exit phase, and the enforcement
  *mechanism* (rewriting the syscall number, SIGKILLing the tree).
- Summary, ProcStat, and Reporter move to engine.rs and are re-exported
  from tracer.rs, so wraith::tracer::{...} paths stay source-compatible.

Behavior is unchanged: the map dirty/refresh timing, syscall counting on
a lost getregs, the CRITICAL-only enforcement gate, and the fatal-fault
signal path are all preserved. Full suite (37 unit + 5 bin + 10
integration) passes and clippy is clean; a live run still reports benign
as clean and shellcode-sim as an EXPLOITATION CHAIN.

An eBPF backend can now implement Backend and reuse the entire Engine,
swapping only how a syscall stop is obtained.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FiEuoW9Kpfw6Gv1d3pCXgs

Author: claude

README.md

@@ -237,7 +237,8 @@ carry the smallest supply chain you can manage. The engine links only `nix` and
    ├─ syscalls.rs    the syscall table Wraith cares about
    ├─ detect.rs      the invariants + the exploitation-chain correlator
    ├─ event.rs       detection events + their JSONL form
-   ├─ tracer.rs      the ptrace engine (spawn/attach/scan, thread-following, enforcement)
+   ├─ engine.rs      the transport-agnostic detection core (Backend trait, Engine)
+   ├─ tracer.rs      the ptrace Backend (spawn/attach/scan, thread-following, enforcement)
    ├─ ui.rs          the live terminal dashboard (--ui), hand-rolled ANSI
    └─ bin/
        ├─ wraith.rs           the CLI sensor
@@ -251,6 +252,15 @@ The tracer adds no syscall of its own on the hot path beyond the unavoidable
 `getregs`, and re-reads `/proc/<pid>/maps` only when a memory operation could
 have changed it.
 
+**Transport-agnostic core.** Detection is split from transport behind a
+`Backend` trait. The `ptrace` tracer is the first backend: it captures each
+syscall-entry into a neutral register snapshot and hands it to the shared
+`Engine`, which owns the cached memory map, the per-process stats, the detector,
+and the enforce-on-CRITICAL policy — and never issues a `ptrace` call itself.
+The same `Engine` drives any transport unchanged, so the planned eBPF backend
+(below) reuses the entire detection model and only swaps how a syscall stop is
+obtained.
+
 **Thread-following.** Real targets — network daemons, request handlers, fuzz
 harnesses — are multithreaded, and an exploit can fire from any thread. Wraith
 follows every `clone`/`fork`/`vfork` the target makes and inspects syscalls
@@ -270,7 +280,11 @@ claim to be a finished EDR.
   (network daemons, parsers, fuzz targets), not the whole system. The
   production path is the same logic on **eBPF** (`tracepoint/raw_syscalls` +
   a page-provenance map) for near-zero overhead — the detection model is
-  transport-agnostic by design.
+  transport-agnostic by design, and now lives behind a `Backend` trait
+  (`src/engine.rs`) so that eBPF backend slots in beside the `ptrace` one
+  without touching detection. (eBPF observes rather than stops, so it would be
+  the low-overhead *observe* backend; `ptrace` stays for lossless capture and
+  `--block`/`--kill`, which need the tracee held at syscall entry.)
 - **Attach vs. pre-existing threads.** `wraith run` and `wraith attach` follow
   every thread and child the target spawns *after* tracing begins (via
   `PTRACE_O_TRACECLONE`/`FORK`/`VFORK`). When attaching to an already-running