Honest data-speed verdicts for Thunderbolt docks and drives

What's fixed

The data-speed verdict no longer cries wolf on Thunderbolt docks, TB3 devices, or cables with sketchy e-markers (issue #190). The verdict feature shipped four days ago in v0.12.0, and @i0ntempest's four-port report on a Mac Studio M4 Max surfaced three distinct ways it could go wrong:
- For a TB4 dock or TB5 SSD, the verdict was reading the device's speed off the internal USB hub chip inside the dock (5 or 10 Gbps) instead of the dock itself. Result: "Device runs at 10 Gbps" on what is actually a 40 or 80 Gbps device. The Mac's Thunderbolt graph already knows the dock's real capability and now drives the verdict.
- For a TB3-only / SATA-only drive (e.g. LaCie d2), no USB device was visible to compare against, so the verdict assumed "the device can do anything the Mac can" and blamed the cable. Replacing the cable would not have helped because the drive caps at TB3 speed. The connected Thunderbolt partner's cap now drives the verdict. Cables only get blamed when they are actually the limit.
- For a cable whose e-marker chip over-states its speed (an 80 Gbps claim on what is actually a 40 Gbps cable), the verdict trusted the inflated claim and reported "running slower than expected" with a back-to-front explanation. The Thunderbolt controller's reading now wins on any disagreement, in either direction. The earlier under-reporting case from issue #111 still resolves the same way it always did.

Cable-signal-conflict callout rewritten. The Pro Negotiation Diagnostics callout that explains an e-marker / controller mismatch was one-directional ("e-marker under-reports..."). It now covers both directions: active cables that under-report their speed AND suspect cables whose e-markers over-state. The controller's reading is treated as authoritative.

A new sanity floor on the resolved cable speed: it cannot sit below the link's negotiated rate. If a controller reading would put it lower, the negotiated rate wins, because the cable must physically be able to carry what the link is actually running.
Ten new unit tests covering the affected scenarios, including a regression guard against the wrong field being used to find a Thunderbolt partner (caught by adversarial review during the fix: a partner switch's own upstream port number is not the same thing as the parent's downstream port number).

Thanks @i0ntempest for the clean four-port report with full JSON.