M4-P0C2 — Three on-wire SV publishers, one qualified EMAC/PTP timebase

Requires: M4-P0A #334 (merged), M4-P0B #335 (merged), M4-P0C1 PR #336 (three-profile firmware staging/commit; under CI). Parent milestone: #333. Architecture: M4 ARD.

Operator outcome

On one powered ESP32-P4, compile and deploy the provided three-MU SCD through Studio (after GUI work), then START three independent canonical 4I+4V SV streams: MU01_SV1 to MAC 01:0C:CD:04:00:01, MU01_SV2 to ...:02, MU01_SV3 to ...:03, all APPID 0x4000, 802.1Q VID 0 PCP 4, 4000 frames/s per MU, 12,000 canonical fps total. All derive smpCnt, clock epoch and smpSynch from ONE PTP-connected sampling authority. Each has isolated 4I+4V values/phase/quality and TX telemetry. Do not claim physical simultaneous egress from one Ethernet MAC, just a common sampling instant and bounded measured egress separation.

Implementation sequence — code tasks

1. Immutable roster promotion: expose P0C1 MultiSvConfigStore's validated committed three-profile bank as one generation/hash-controlled snapshot. Add an M4-specific activation command and capability SV-MULTI3-V1 only when the TX runtime actually supports it. Do not point the old PROFILE V1 START at a multi-roster. Require ALL STREAMS STOPPED for immutable identity/layout switches; snapshot safely outside the 4-kHz ISR.
2. Three contexts, not three executors: introduce a fixed std::array<SvStreamRuntime,3> under embedded/esp32p4_smv_injector/main/, each containing its own compiled RuntimePublisherProfile, independently prebuilt canonical frame template/payload area, SvLiveSignalBank, SvFixedPointSineEngine, SvCounters, enabled/RUNNING/FAULT state and setpoint generation. Do not share mutable bytes or phase accumulator. Share only read-only sine LUT/wire-layout math. Initialize all streams before timer enable.
3. ONE scheduler and ONE PTP decision per grid tick: reuse existing app_main.cpp's EMAC/PTP clock-lease observation and GPTimer (including PTP-phase qualification/fail-closed policy). Refactor the current 4-kHz publisher_task rather than running three independent FreeRTOS TX tasks. For tick index k, produce the same smpCnt=k % 4000 on all active streams, based on one source epoch/lease and one smpSynch decision. Per-stream waveform phase remains independent of scheduling phase. Clock-source changes revoke the group's synchronized state together.
4. Deterministic Ethernet burst: each valid grid tick patches and dispatches at most three canonical SV packets MU1→MU2→MU3 over existing EMAC/driver, using fixed templates, no heap/logging in hot path. Old 4kHz diagnostic mirror must not be multiplied by three; disable/decimate diagnostic frames initially. Respect PTP Sync/Follow Up TX timing on same MAC. Record slot miss, three-packet burst latency, PTP epoch delta, TX error per slot. Never replay stale missed samples in a flood.
5. Start/Stop and autonomy: independent stream start/stop at the next common tick without resetting unaffected smpCnt or DDS phases. START ALL is an atomic requested mask on a single qualified epoch, not three asynchronous starts. Closing Studio/USB must keep previously RUNNING outputs; reconnect adopts actual per-slot statuses. Ethernet physical link DOWN stops traffic fail-closed.
6. Regression and CI gates: host-level schedule test for 4000 ticks/one PTP second with three independent counters and exact 12k intended frames; per-slot RMS/phase edits do not affect siblings; stream 2 restart joins current grid without touching streams 1/3; codec produces distinct MAC/svID/APPID/VLAN with exactly 8 INT32+Quality pairs per stream; PTP source/epoch revocation is group-coherent; stress asynchronous serial updates and Ethernet link-down. Compile firmware in ESP32-P4 and PTP SOURCE/RECEIVER workflows, then ordinary Wireshark/Npcap capture on isolated LAN and report actual observed throughput and jitter.

Performance gate

250 µs per common sample slot. Profiling must include three packet encodes/patches + esp_eth_transmit timing, driver ring pressure, memory high-water mark, and PTP coexistence. Real emitted SV wire length drives the bandwidth calculation. No magic FPS assumptions or three RTOS task stacks. If hardware timing exceeds the budget, optimize precomputed BER offsets/packet buffers and bounded Ethernet dispatch before widening scope.

This issue is P0C2 firmware, not a request to buy GPS/PTP/relay hardware. M3.H.3 stable untouched until a matched M4 firmware/Studio preview actually produces three on-wire streams.