Integrate DS4 execution parity in Rust

PLAN.md

@@ -45,18 +45,31 @@ execution targets one self-contained Mac.
 - Focused coverage exercises triggers, summary bounds and sanitizing, tail
   selection, queued guidance, checkpoint identity, running jobs, durable
   compaction markers, relaunch, and continued tool work after rebuild.
-- The next baseline gap is SSD streaming. Speculative decoding, steering, GLM
-  5.2 execution, and DeepSeek V4 Pro execution are not implemented in the Rust
-  executor. Related catalog, validation, and preference plumbing must not be
-  treated as runtime support.
+- DeepSeek V4 Flash now supports DS4-compatible SSD expert streaming, legacy
+  MTP, DSpark, and directional steering in the Rust executor. The optional
+  modes are integrated into the same target-owned generation path used by
+  local chat and the endpoint; disabling them preserves the resident greedy
+  token baseline. Runtime counters feed the Stats dashboard without inference
+  thread UI work.
+- Hardware-backed token oracles cover resident versus SSD execution, legacy
+  MTP, DSpark, SSD combined with both speculative modes, directional steering,
+  and target-only fallback. Differential endpoint scripts cover deterministic
+  output, finish state, and usage when reference and Rust servers are supplied.
+- GLM 5.2 has a dedicated Rust/Metal executor and DeepSeek V4 Pro uses the
+  generalized DeepSeek graph. Their remaining work is validation rather than
+  catalog plumbing: GLM MTP is still rejected, the full GLM/Pro hardware matrix
+  is incomplete, and Pro still needs explicit memory-admission verification.
+- The remaining model-independent execution gaps are fine-grained SSD cache
+  telemetry, the DS4 expert-locality profiler, and resident multi-session
+  server batching/scheduling.
 
 ## Delivery order
 
-1. **Next:** remaining DS4 execution technology, starting with SSD streaming, then
-   speculative decoding and the other Metal/runtime parity work.
-2. Additional model execution: GLM 5.2 and DeepSeek V4 Pro.
-3. Product completion, exhaustive parity verification, and distribution.
-4. Optional extensions: Dev Brain and A2UI.
+1. **Next:** finish the remaining DS4 execution parity: detailed SSD cache
+   telemetry, expert profiling, resident multi-session batching, GLM MTP, and
+   the GLM/Pro hardware matrix.
+2. Product completion, exhaustive parity verification, and distribution.
+3. Optional extensions: Dev Brain and A2UI.
 
 ## 1. Completed — tool hardening and safety
 
@@ -95,13 +108,21 @@ Exit criterion: use the agent for a real inspect/edit/test cycle while every
 side effect is visible, risky actions require consent, Stop works at every
 stage, and no file tool can escape the selected project.
 
-## 2. DS4 execution technology parity
+## 2. In progress — DS4 execution technology parity
 
 Goal: finish the model-independent Metal/runtime capabilities in `ds4.c`
 before adding larger model families. Every capability must be shared by local
 chat and the HTTP endpoint through the single process-wide model owner.
 
-### 2.1 SSD streaming — first runtime priority
+### 2.1 Implemented — SSD streaming
+
+Flash routed experts stream through the unchanged DS4 Metal kernels with
+automatic or explicit cache budgets, cold start, generated DS4 hotlists,
+preload controls, asynchronous I/O, and bounded cache eviction. Resident and
+SSD generation share token oracles. Engine atomics expose resident/cache bytes,
+requests, bytes read, and wait time; the UI samples and graphs their rates on
+its normal metrics thread. Native cache hit/miss, eviction, and preload-progress
+telemetry remains to be surfaced without changing the carried-over kernels.
 
 SSD streaming is the capacity prerequisite for larger models and therefore
 comes before GLM 5.2 and DeepSeek V4 Pro execution.
@@ -122,7 +143,14 @@ comes before GLM 5.2 and DeepSeek V4 Pro execution.
   the cache and I/O layer model-aware so later GLM/Pro milestones add policy and
   graph support rather than a second streaming subsystem.
 
-### 2.2 Speculative decoding: legacy MTP and DSpark
+### 2.2 Completed for Flash — legacy MTP and DSpark
+
+Both support GGUF formats are validated and executed by Rust. Draft generation,
+confidence/margin gates, target verification, accepted-prefix commit, rollback,
+strict/quality fallback, cancellation, checkpoint identity, streaming output,
+usage accounting, and Stats counters use the existing generation lifecycle.
+Sampled decoding remains target-only as in DS4. SSD streaming works with both
+modes, and long-chat DSpark prefill has a dedicated hardware regression.
 
 - Load and validate the optional Flash legacy-MTP or DSpark support GGUF without
   treating either as a standalone model. Preserve exact support-kind and target
@@ -142,7 +170,12 @@ comes before GLM 5.2 and DeepSeek V4 Pro execution.
 - GLM's in-model MTP path belongs to the GLM milestone, but it should reuse the
   verifier/session machinery established here.
 
-### 2.3 Remaining Metal execution controls
+### 2.3 Mostly completed — remaining Metal execution controls
+
+Directional steering, power throttling, prefill chunking, quality mode, weight
+warming, and simulated memory pressure now affect execution. CPU helper-thread
+and expert-profile settings are rejected instead of being persisted no-ops.
+Porting DS4's expert-locality profile output is the remaining item here.
 
 - Port directional steering files and exact FFN/attention application,
   including DS4 defaults, validation, zero-scale behavior, and checkpoint/model
@@ -154,7 +187,7 @@ comes before GLM 5.2 and DeepSeek V4 Pro execution.
 - Add hardware-backed token/activation fixtures for each mode and keep the
   ordinary resident Flash path unchanged when optional features are off.
 
-### 2.4 Single-machine server batching
+### 2.4 Remaining — single-machine server batching
 
 - Port DS4's resident multi-session batching and server scheduling only after
   the serialized path remains the correctness oracle. Preserve per-request
@@ -169,11 +202,12 @@ resident, SSD-streamed, MTP, DSpark, steering, and batched-server
 configurations, with optional modes off producing the same baseline behavior
 as today.
 
-## 3. Additional model execution
+## 3. Implemented executors — additional-model validation remains
 
-Start these only after the shared capacity and execution technology above is
-stable. Catalog entries, settings, tokenizer work, or GGUF validation alone do
-not make a model selectable for inference.
+GLM 5.2 has a dedicated DSA/MLA executor and DeepSeek V4 Pro uses the generalized
+DeepSeek graph. Both are selectable runtimes, not catalog-only placeholders.
+They are not complete parity milestones until the remaining items below pass on
+the installed hardware fixtures.
 
 ### GLM 5.2