Cable-latency trust signal, USB-IF certification ID and 0xFFFF in cable reports

What's new

• New trust signal: cable e-marker uses a reserved cable-latency value. The Cable VDO carries a 4-bit "Cable Latency" field that maps roughly to one-way cable latency (and, for passive cables, approximate length at 10 ns per metre). The USB-PD spec defines 0000 and 1001..1111 as Invalid for passive cables, and 0000 and 1011..1111 as Invalid for active cables (active cables additionally use 1001 and 1010 for optical-cable latencies). WhatCable now flags any reserved value, with cable-type-aware bounds. Wording stays hedged, same as the existing reserved speed and current flags.

• Cable reports now include the USB-IF certification ID (XID). The Cert Stat VDO carries an XID that USB-IF assigns before product certification. This is a fact about the e-marker, not a trust signal: many reputable cables (including the Anker and Caldigit examples on file) ship without going through USB-IF certification, so a missing XID is normal. The cable report markdown now includes a "USB-IF certification ID" row showing either the hex XID or "none (XID = 0)".

• VID 0xFFFF is now described accurately, not flagged as a warning. The USB-PD spec defines 0xFFFF as the legitimate "vendor not registered with USB-IF" sentinel (with PID forced to 0x0000). It's allowed by the spec, so flagging it as a trust warning would be misleading. WhatCable now surfaces it as a vendor name ("No vendor ID assigned (USB-PD spec sentinel)") and stops short of generating a trustFlags entry. VID = 0x0000 continues to fire zeroVendorID (the stronger "blank field" signal).

Internal

• New PDVDO.CertStat struct and PDVDO.decodeCertStat function for vdos[1], surfaced via PDIdentity.certStatVDO.
• New cableLatencyEncoded field and latencyNanoseconds helper on PDVDO.CableVDO. The helper returns nil for reserved values, and the spec-defined 1001/1010 optical entries are gated on cableType == .active.
• TrustFlag enum gains reservedCableLatencyEncoding(Int). JSON code strings are stable and pinned in tests.
• VendorDB.name(for:) now special-cases 0xFFFF so the cable report and popover describe the spec sentinel without going through Unregistered / unknown.
• CableReport.CableFingerprint gains usbifCertID: UInt32?.
• VBUS Current 00b is intentionally NOT flagged for v0.8.3, even though the spec lists it as Invalid: real USB 2.0 cables emit it routinely, so the false-positive rate would be high. There's a comment in decodeCableVDO recording that decision.
• planning/spec-reference.md is the canonical bit-level reference for these (and for the validation rules not yet shipped, like raw-PDO range checks).