docs: frame the single-cycle / wavetable direction, eight forks open

Where the instrument's loop grid, crossfade and pitch handling stop making
sense as a capture shrinks toward one cycle, and what "wavetable synth" would
mean here. Two structural results: the pre-seam crossfade is the identity map
at one-period loop lengths, and YIN cannot detect a single cycle, so the period
is declared rather than detected there. Four candidate shapes, W3 recommended
out. PLAN.md gets a pointer under "Flagged for awareness" only.

docs/PLAN.md

@@ -215,6 +215,34 @@ in Γ-W4-T1 and changes no wave boundary.
      is `docs/product/parameter-automation.md` §8. **That doc is no longer scoping-only —
      §§6–10 are the specification Γ-W4-T1 is built from.**
 
+4. **Single-cycle material and the wavetable direction is FRAMED but is NOT a phase, and
+   deliberately so.** Daniel, 2026-08-03, after DAW-testing a one-cycle 60 Hz sine capture:
+   *"supporting smoothness at this micro scale would turn this into a wavetable synth, which
+   is desirable."* The product framing is `docs/product/single-cycle-and-wavetable.md`.
+
+   **It carries EIGHT open [Daniel]-class forks and none is ruled**, so it gets a pointer
+   here rather than a phase section: `PLAN.md` is the active on-deck specification list, and
+   a phase with eight unruled forks is neither briefable nor consistent with the standing
+   claim above that **Λ is the only phase in this plan with unanswered [Daniel]-class
+   questions**. That claim is unaffected by this item — there is no phase here to except.
+   When the forks are ruled, the doc becomes a phase's backing product doc in the ordinary
+   way (the Γ / Ε / Ρ / Λ pattern, not the doc-less Ψ / Ω one).
+
+   **Two things in it are decision-grade for work already in this plan, which is why it is
+   flagged rather than merely filed:**
+
+   - **The immediate defect it came from is NOT its subject.** `nearestZeroCrossing`
+     (`src/core/instrument/ui/waveform_view.cpp:181-210`) fans out across the whole buffer
+     with no radius bound; a snap-radius track is in flight against it. **But Phase Ω's own
+     acceptance criteria name the zero-crossing snap as a thing that "must come out the other
+     side identical", and Ω-W1-T5's outline entry repeats it.** A snap-radius change alters
+     exactly that behaviour. **Whoever owns Ω's criteria must reconcile the two** — this item
+     records the conflict, it does not resolve it.
+   - **Sequencing, if any of it is ever dispatched.** Every candidate touches
+     `waveform_view.{h,cpp}`, `editor_input_waveform.cpp` and `editor_controls.cpp`'s
+     `waveMarksFor` / `grabbableMarks` — Ω-W1-T5's exact surface. Nothing from that doc
+     should dispatch until Ω-W1-T5 and the snap-radius track have both landed.
+
 ## Phase-wide acceptance criteria
 
 These bind every track in this plan and are stated once here rather than repeated