docs(perf #N6.1): apply code-quality review fixes to baseline doc

Code-quality review on commit 13abf96 flagged 3 Important issues in
the baseline document plus 2 minor roadmap consistency gaps. Applied
all of them:

1. The "CPU scales superlinearly with N₁" claim was imprecise because
   CPU growth (4.0×) is actually sublinear vs near-LB count (7.7×).
   Clarified: CPU grows more than linearly with radius N₁ but
   sublinearly with visible-LB count; frustum cull discards most far
   LBs early. The outer per-LB walk still scales with N₁, which is
   what Tier 2's persistent groups address.

2. The "40-50% memory footprint reduction from atlas packing" estimate
   was asserted without derivation and likely too optimistic given all
   surfaces are already power-of-two and same-format (RGBA8). Replaced
   with a more honest bound: "low-MB to ~10 MB absolute saving" with
   explicit per-array metadata overhead reasoning. Conclusion is
   unchanged — atlas adoption still isn't justified given GPU
   under-utilization.

3. The "spec §6 threshold for atlas is >30%" citation pointed at text
   that doesn't exist in the spec. Replaced with "A conventional
   rule-of-thumb" so a future reader doesn't chase a phantom citation.

Plus roadmap consistency:

M1: The N.6 slice 1 bullet now uses the canonical "✓ SHIPPED — Title.
   Shipped YYYY-MM-DD." prefix that every other shipped phase uses.
M2: Added N.6.1 row to the shipped table at the top of the roadmap
   (lines ~55-66) so the at-a-glance shipped list is complete.

None of these change the conclusion or the next-phase recommendation
(C.1.5 first, then reduced N.6 slice 2). The fixes improve doc accuracy
and future-readability.

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

docs/plans/2026-05-11-phase-n6-perf-baseline.md

@@ -87,9 +87,9 @@ Same as the dimension buckets above since there is only one format. The top-3 tr
 (128×128, 64×64, 256×256) cover 449 of 760 surfaces = **59%**.
 
 **Atlas-opportunity score: 59%** of surfaces fall into the top-3 (W, H, format) triples.
-The spec §6 threshold for "atlas work is justified for memory savings" is >30%; this
-measurement is well above it. However, see §4 for why atlas is not the right next step
-despite the high score.
+A conventional rule-of-thumb is that >30% concentration into the top buckets makes atlas
+packing worth the implementation cost for memory savings; this measurement is well above
+that. However, see §4 for why atlas is not the right next step despite the high score.
 
 ## §4. Conclusion + next-phase recommendation
 
@@ -105,13 +105,17 @@ walking — against a 16,600 µs frame budget at 60 FPS. The GPU is working at r
 particles, UI, and swap-buffer overhead, there is substantial headroom. The "GPU
 comfortable" threshold (gpu_us p95 < 8,000 µs) is not even close to being challenged.
 
-**CPU scales superlinearly with N₁ (near-tier radius).** As N₁ grows from 4 → 8 → 12,
-median cpu_us grows from 3.2 ms → 6.7 ms → 12.9 ms — roughly 1.0× → 2.1× → 4.0× the
-r4 baseline. The Tier 1 entity-classification cache (`EntityClassificationCache`, shipped
-as #53) wins on the inner loop (per-entity classification avoided on cache hits) but the
-outer per-LB walk still scales with N₁. This is exactly what the Tier 2 plan (persistent
-groups) at `docs/plans/2026-05-10-perf-tiers-2-3-roadmap.md` addresses by eliminating
-the per-frame LB scan entirely.
+**CPU grows more than linearly with N₁ (near-tier radius), but sublinearly with
+visible-LB count.** As N₁ grows from 4 → 8 → 12, median cpu_us grows from 3.2 ms →
+6.7 ms → 12.9 ms — roughly 1.0× → 2.1× → 4.0× the r4 baseline. The visible-LB count
+scales as `(2N+1)²`: 81 → 289 → 625, so CPU growth is sublinear in LB count (4.0×
+vs 7.7× expected if every LB cost the same). Frustum culling discards most far LBs
+early, but the outer per-LB walk still has to touch each one. The Tier 1 entity-
+classification cache (`EntityClassificationCache`, shipped as #53) wins on the inner
+loop (per-entity classification avoided on cache hits) but the outer walk dominates
+as N₁ grows. This is exactly what the Tier 2 plan (persistent groups) at
+`docs/plans/2026-05-10-perf-tiers-2-3-roadmap.md` addresses by eliminating the
+per-frame LB scan entirely.
 
 **Radius=12 is not the production scenario.** `ACDREAM_STREAM_RADIUS=12` forces N₁=12
 (625 near LBs at full detail). The production A.5 default preset is N₁=4 / N₂=12 (81
@@ -119,13 +123,18 @@ full-detail near + 544 terrain-only far), which CLAUDE.md already characterizes
 comfortable 200–400 FPS at the default preset. The numbers above characterize the scaling
 curve for headroom analysis, not the experience a typical player sees.
 
-**Atlas opportunity is high (59%) but the win is memory-only.** With 96 MB of textures
-and 59% in the top-3 dimension buckets, atlas consolidation would reduce sampler-switch
-count (currently near-zero already, since bindless textures are made resident once) and
-shrink the texture memory footprint by roughly 40–50% through packing. But GPU is not
-bottlenecked on sampler switches or memory bandwidth — the 0.6 ms gpu_us p95 at radius=12
-walking demonstrates this directly. Atlas adoption would cost 1–2 weeks of implementation
-risk for a memory saving the process doesn't currently need at 96 MB.
+**Atlas opportunity is high (59%) but the win is memory-only — and modest.** With 96 MB
+of textures and 59% in the top-3 dimension buckets, atlas consolidation would let the
+top buckets share single `Texture2DArray` objects rather than each surface owning its
+own 1-layer array. The primary wins of atlas — fewer sampler switches, fewer texture
+binds — are already near-zero because bindless textures are made resident once at upload
+and never bound per draw. The remaining win is the per-array metadata overhead × N
+surfaces, which is bounded but not dramatic given all surfaces are already power-of-two
+and same-format (RGBA8). Even on the optimistic side, the absolute memory saving is on
+the order of low-MB to ~10 MB, not a 40–50% halving. GPU is not bottlenecked on sampler
+switches or memory bandwidth (0.6 ms gpu_us p95 at radius=12 walking demonstrates this
+directly), so atlas adoption would cost 1–2 weeks of implementation risk for a memory
+saving the process doesn't currently need at 96 MB.
 
 ### Recommendation