Implement Supervision CC

.github/copilot-instructions.md

@@ -87,12 +87,13 @@ Implements Z-Wave Command Classes (Z-Wave Application Specification). This proje
 
 ### High-Level Objects (`src/ZWave/`)
 
-- **`Driver`** — Entry point. Implements `IDriver`. Opens serial port, manages frame send/receive, processes unsolicited requests, coordinates request-response and callback flows. Tracks `NodeIdType` (default `Short`) and creates `CommandParsingContext` instances to pass when parsing incoming frames. Handles encapsulation/de-encapsulation of Multi Channel frames per spec §4.1.3.5: on send, wraps commands targeting endpoint > 0 in Multi Channel Command Encapsulation (source=0, destination=endpointIndex); on receive, detects incoming Multi Channel encapsulation frames, extracts the inner command and source endpoint, and routes the inner frame to the correct endpoint's CC handlers. Future encapsulation layers (Supervision, Security, Transport Service) plug into the same send/receive hooks in the spec-defined order.
+- **`Driver`** — Entry point. Implements `IDriver`. Opens serial port, manages frame send/receive, processes unsolicited requests, coordinates request-response and callback flows. Tracks `NodeIdType` (default `Short`) and creates `CommandParsingContext` instances to pass when parsing incoming frames. Handles encapsulation/de-encapsulation per spec §4.1.3.5 order. On receive (reverse order): Security/CRC-16/Transport Service → Multi Channel → Supervision → Multi Command. On send: payload → Multi Command → Supervision → Multi Channel → Security/CRC-16/Transport Service. Currently implements Multi Channel and Supervision layers; future encapsulation layers (Security, Transport Service) plug into the same hooks. For incoming Supervision Get frames, the Driver de-encapsulates the inner command, processes it, and sends back a Supervision Report (SUCCESS) — unless the frame was received via multicast/broadcast, per spec CC:006C.01.01.11.005. Incoming Supervision Report frames are routed directly to the node's Supervision CC instance.
 - **`Controller`** — Represents the Z-Wave USB controller. Runs identification sequence on startup. Negotiates `SetNodeIdBaseType(Long)` during init if supported by the module. Stores mutable `Associations` list for the controller's lifeline group (modified when other nodes send Association Set/Remove).
 - **`ControllerCommandHandler`** — Handles incoming commands from other nodes directed at the controller (the "supporting side"). When another node queries the controller (e.g., Association Get, AGI Group Name Get), this class dispatches to the appropriate handler which constructs and sends the response. Lives in the Driver layer (not the CC layer) because handlers need Driver/Controller context. Uses fire-and-forget for async responses to avoid blocking the frame processing loop.
 - **`Node`** — Represents a Z-Wave network node. Implements `INode` (and thus `IEndpoint` with `EndpointIndex = 0`). A node IS endpoint 0 (the "Root Device"). Contains a dictionary of child `Endpoint` instances (1–127) discovered via the Multi Channel CC interview. Key methods: `GetEndpoint(byte)`, `GetAllEndpoints()`, `GetOrAddEndpoint(byte)`. The `ProcessCommand` method accepts an `endpointIndex` parameter to route frames to the correct endpoint's CC instance. The interview follows a phased approach per spec: Management CCs → Transport CCs (Multi Channel discovers endpoints) → Application CCs on root, then repeats for each endpoint. Node IDs are `ushort` throughout the codebase to support both classic (1–232) and Long Range (256+) nodes.
 - **`Endpoint`** — Represents a Multi Channel End Point (1–127). Implements `IEndpoint`. Holds its own CC dictionary (copy-on-write), device class info (`GenericDeviceClass`, `SpecificDeviceClass`), and provides `ProcessCommand`, `AddCommandClasses`, `InterviewCommandClassesAsync` methods. Created during the Multi Channel CC interview.
 - **`MultiChannelCommandClass`** — Implements the Multi Channel CC (version 4) in `src/ZWave.CommandClasses/`. Discovers endpoints during interview by sending EndPoint Get and Capability Get commands. Provides static methods `CreateEncapsulation()` and `ParseEncapsulation()` used by the Driver for its encapsulation pipeline. Exposes `internal event Action<TReport>?` events (`OnEndpointReportReceived`, `OnCapabilityReportReceived`, `OnCommandEncapsulationReceived`) that fire on both solicited and unsolicited reports. Node subscribes to `OnCapabilityReportReceived` to create Endpoint instances. The interview flow per spec §6.4.2.1: EndPoint Get → for each EP: Capability Get. If Identical flag is set, queries only EP1 and clones for others. Note: The Driver handles Multi Channel de-encapsulation of incoming frames upstream (in `ProcessDataFrame`), so `ProcessUnsolicitedCommand` for `CommandEncapsulation` is only reached if frames are routed to the CC directly (not the normal path). This report-event pattern is the convention for all CC implementations.
+- **`SupervisionCommandClass`** — Implements the Supervision CC (version 2) in `src/ZWave.CommandClasses/`. Provides application-level delivery confirmation for Set-type and unsolicited Report commands. A Transport CC (interviewed after Management CCs) with no mandatory interview. Provides static methods `CreateGet()`, `ParseGet()`, `CreateReport()`, `ParseReport()` used by the Driver for encapsulation/de-encapsulation. The `SupervisionGet` record wraps an encapsulated command with a 6-bit session ID (0-63) and a `StatusUpdates` flag. The `SupervisionReport` record carries status (`NoSupport`, `Working`, `Fail`, `Success`), duration, and v2's `WakeUpRequest` bit. The Driver handles de-encapsulation in its receive path and automatic Supervision Report responses. Future work: wrapping outgoing Set commands with Supervision Get (send-side, requires status state machine).
 
 ### Source Generators (`src/ZWave.BuildTools/`)