Display Diagnostics calls compressed (DSC) modes "running at full quality", and the built-in HDMI port label matches the main view

Two display-side fixes from real reports.

Fixed

Display Diagnostics no longer reads compressed (DSC) modes as a refresh-rate fault. On displays that genuinely need compression to reach their best mode, like 4K120 over DisplayPort 1.4 or 5K60 on a Studio Display, the diagnostic was warning "monitor can do more than the link is carrying" and pointing at the resolution or refresh rate setting. It now recognises when the picture is reaching the display through compression and calls it out as a positive verdict, "running compressed (DSC) to fit through the link", with no warning. Driven by the live on-screen mode and the link's actual bandwidth, and accounts for 10-bit / HDR colour modes so an HDR display isn't mistaken for DSC. Behind the scenes, this is the empirical case (DSC provably active right now); the existing "at the DisplayPort ceiling" carve-out from v0.21 still handles the inferred case.
Built-in HDMI port label matches across the app. On Macs with a native HDMI port (M3 Pro/Max, M4, M5 MacBook Pros and the Mac mini / Studio), the main view and Display Diagnostics were showing different port numbers for the same physical connection: the main view called it "Built-in HDMI port 1", while Display Diagnostics called it "HDMI port 2". Two different IOKit fields, neither path knew about the other. Now both surfaces agree. Thanks to @jimmyorz on issue #362.

The --json output now includes the live bits-per-channel value the display diagnostic used (8 for standard colour, 10 for HDR / 10-bit), so a whatcable --json consumer can see exactly which arithmetic produced the DSC verdict.