fix(wireless): attribute CAP radios to the access point, not the controller (v0.23.1-beta)

Third round of #94 field testing. The placement bug survived v0.23.0 because the
previous fix addressed the wrong mechanism.

Cause
  A CAPsMAN controller mirrors every CAP interface locally, so a CAP's radio MAC
  legitimately appears on two devices: the CAP that owns the hardware, and the
  controller that mirrors it. The MAC index was single-valued and first-wins over an
  unordered UNION, so each radio landed on whichever row the database happened to
  return first. On the reporter's fleet six radios attached to a router with no
  radios at all, while their siblings attached correctly — the same access point
  appearing in two places, and liable to move between polls.

  v0.23.0 excluded the controller from *prefix* matches only. These are exact
  matches, so the exclusion never applied. Consecutive MACs on one physical AP
  resolving to different devices is what gave it away.

Fix
  The index is multi-valued: a MAC maps to every device carrying it. A radio the
  controller reports as local:false lives on a CAP by definition, so the controller
  is rejected as a candidate at exact strength as well as prefix — an exact match
  against it only ever means the mirror. Attribution now runs through
  matchRadiosToDevices, which was previously tested but unused while the collector
  kept its own copy of the logic.

  With no radios left attributed to it, a controller that has none of its own stops
  appearing in the access point list, which was the reporter's follow-up point.

SSID on provisioned interfaces
  A CAP holds no configuration, so its interface rows carry a generic name and a
  null SSID. The controller knows it, on its mirror of the same interface. Radios
  now record the provisioned SSID from there, and the table is driven by the
  controller's radio list rather than the CAPs' own rows — the controller is the
  only side that knows the SSID, channel and client count together.

Band and frequency columns removed
  Both were empty while the channel column beside them read 5680/ax/eCee/D. The
  channel string already carries the band and the extension layout; parsing it
  properly is its own task, and half-parsing it produced empty columns next to
  populated ones. Requested by the reporter.

75 tests across the CAPsMAN and topology modules, including fixtures built from the
reporter's MAC set: both radios of one AP resolve to that AP, order-independently,
with a genuinely local radio still landing on the controller and an unknown CAP left
unattributed rather than absorbed. Reproduced the mirror scenario against the local
fleet before and after.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.vscode/settings.json

@@ -0,0 +1,5 @@
+{
+    "editor.fontSize": 22,
+    "workbench.colorTheme": "Visual Studio Light",
+    "window.autoDetectColorScheme": true
+}