docs(perf #N6.1): apply final-review fixes — spec, baseline doc, issue #55

Final code review of slice 1 flagged one Important issue (the spec's
"zero cost when off" claim for the surface-dump path is technically
violated — _uploadMetadata always writes one dict entry per upload
regardless of env var) plus minor doc/consistency gaps. Applied:

1. Spec §5 "Cost when off": dropped the "Zero" claim; replaced with
   "Negligible — one Dictionary write per upload (~30-50 KB at Holtburg)
   plus a hash-table write per upload. Expensive work (file I/O,
   histogram construction) is still env-gated." This matches reality.

2. Baseline doc §5: rewrote from "Raw logs (scratch, can be deleted)"
   referencing files that were never preserved in this worktree, to
   "Reproducing the measurements" with the actual PowerShell launch
   commands. Honest about the raw logs not being kept; the captured
   medians in section 2 are the canonical record.

3. New issue #55 filed in docs/ISSUES.md — static-entity slow path
   reports ~1.45M meshMissing/5s at r4 standstill, drops to ~0 when
   walking. LOW severity (no visible regression), hypothesis points
   at a "permanently-missing entity gets re-classified every frame"
   pattern that Tier 1 cache doesn't cover.

4. Roadmap shipped table: renamed "N.6.1" row to "N.6 slice 1" to
   match every other artifact's naming. Search-discoverability fix.

None of these change the slice's conclusion or next-phase
recommendation (C.1.5 first, then reduced-scope slice 2).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/ISSUES.md

@@ -46,6 +46,40 @@ Copy this block when adding a new issue:
 
 # Active issues
 
+## #55 — Static-entity slow path reports ~1.45M `meshMissing` per 5s at r4 standstill
+
+**Status:** OPEN
+**Severity:** LOW (no visible regression — affects a diagnostic counter, not rendered output)
+**Filed:** 2026-05-11
+**Component:** rendering / `WbDrawDispatcher` static-entity classification path
+
+**Description:** During the Phase N.6 slice 1 baseline measurement (`docs/plans/2026-05-11-phase-n6-perf-baseline.md` §2),
+the radius=4 standstill scenario reported `meshMissing ≈ 1,450,000` per 5-second
+`[WB-DIAG]` window. The same scenario while walking drops to near-zero (`meshMissing = 0`
+in the steady state) as new landblocks stream in and previously-missing meshes resolve.
+This suggests the static-entity slow path's mesh-load lifecycle has some delay before
+populating for newly-streamed content but eventually catches up; the standstill case
+keeps re-counting the same set of entities-with-unresolved-meshes for the duration of
+the run. The counter is per-frame so the absolute number scales with FPS — at the
+measured ~150 FPS that's ~290K reports/s, or ~1900 entities each reported each frame.
+
+**Root cause / status:** Not investigated. Hypothesis: an entity classification path
+counts mesh-missing on every frame for static entities whose `MeshRef` resolution races
+the streaming loader. The Tier 1 cache (#53) populates only for entities whose
+classification succeeded, so persistently-failing entities run the slow path every frame
+forever and bump `meshMissing` every time. If true, the fix is either (a) cache the
+"this entity's mesh genuinely doesn't exist" result so we stop re-checking, or (b)
+deferred-classify the entity once its `MeshRef` resolves.
+
+**Files:** `src/AcDream.App/Rendering/Wb/WbDrawDispatcher.cs` (the slow path that
+increments `_meshesMissing`), `src/AcDream.App/Rendering/Wb/EntityClassificationCache.cs`
+(the Tier 1 cache — likely needs to learn about "permanently missing" entries).
+
+**Acceptance:** `meshMissing` should drop to near-zero within ~5 seconds of streaming
+settle at any radius/motion combination, not stay at ~1.45M/5s indefinitely at standstill.
+
+---
+
 ## #50 — Road-edge tree at 0xA9B1 visible in acdream but not retail
 
 **Status:** OPEN