review(2-6): story 2-6 passes all ACs — mark done, add deferred items

Code review of stateful Renderer and DisplayInterface: all 10 review
criteria pass with no code changes required. Add two deferred items for
WaveshareDisplay NotImplementedError stub (wired in 2-7) and pixel-space
trail staleness on re-provisioning. Mark story done in story file and
sprint-status.yaml.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

_bmad-output/implementation-artifacts/2-6-stateful-renderer-and-display-interface.md

@@ -1,6 +1,6 @@
 # Story 2.6: Stateful Renderer & Display Interface
 
-Status: review
+Status: done
 
 ## Story
 

_bmad-output/implementation-artifacts/deferred-work.md

@@ -148,3 +148,17 @@ Description: `_draw_label` uses `ImageFont.load_default()` which renders at appr
 Story: `2-5-per-aircraft-drawing`
 Category: Technical debt
 Description: Arrow tip distance (12px), base half-width (6px), and base offset (8px) are hardcoded inline in `_draw_arrow`. These control icon size and aspect ratio. For Pi Zero 2W or larger displays these values may need tuning. Future hardening: extract to named constants in `constants.py` (e.g. `ARROW_TIP`, `ARROW_BASE_HALF`, `ARROW_BASE_OFFSET`) so they can be adjusted without touching drawing logic.
+
+---
+
+## Story 2.6: Stateful Renderer & Display Interface
+
+### [2-6] WaveshareDisplay.show() raises NotImplementedError
+Story: `2-6-stateful-renderer-and-display-interface`
+Category: Infrastructure/environment
+Description: `WaveshareDisplay.show()` is a stub that raises `NotImplementedError`. The real SPI driver implementation (using the Waveshare Python library) is deferred to story 2-7. The stub satisfies the `DisplayInterface` protocol structurally but cannot be used in production or tests until story 2-7 wires in the hardware driver.
+
+### [2-6] Trail positions are in pixel space — stale after map re-provisioning
+Story: `2-6-stateful-renderer-and-display-interface`
+Category: Technical debt
+Description: Trail entries are `(x, y)` pixel coordinates computed against the `MapBounds` in use at render time. If map bounds change (e.g. after re-provisioning at a different home location or radius), any trails accumulated before the change will plot at incorrect pixel positions on the new map. At runtime this is unlikely — bounds are fixed at startup — but a future enhancement that supports live re-provisioning without restart would need to flush `Renderer._trails` whenever bounds change.

_bmad-output/implementation-artifacts/sprint-status.yaml

@@ -35,7 +35,7 @@
 # - Dev moves story to 'review', then runs code-review (fresh context, different LLM recommended)
 
 generated: 2026-04-22
-last_updated: 2026-04-22  # 2-1 done, 2-2 done, 2-3 done, 2-4 done, 2-5 done, 2-6 review, epic-2 in-progress
+last_updated: 2026-04-22  # 2-1 done, 2-2 done, 2-3 done, 2-4 done, 2-5 done, 2-6 done, epic-2 in-progress
 project: planeMapper
 project_key: NOKEY
 tracking_system: file-system
@@ -58,7 +58,7 @@ development_status:
   2-3-home-marker-and-airspace-outlines: done
   2-4-altitude-colour-bands-and-aircraft-type-icons: done
   2-5-per-aircraft-drawing: done
-  2-6-stateful-renderer-and-display-interface: review
+  2-6-stateful-renderer-and-display-interface: done
   2-7-operational-radar-loop-startup-screen-and-systemd-wiring: backlog
   epic-2-retrospective: optional