chore(dev): seedable CAPsMAN fixture so managed-wireless paths can be tested (v0.23.8-beta)

Two bugs shipped in the last three releases because CAPsMAN code was written and
"verified" against a fleet that contains no CAPsMAN. Neither was reachable by unit
tests, because both lived in SQL: a join that could never match, and a WHERE clause
that filtered out every managed radio before the analysis ran. Both were found by
the reporter, in production, after release.

The fix is not another test of the pure functions — those were already right. It is
to stop the local environment from being unrepresentative.

scripts/seed-capsman-fixture.sql builds a deployment shaped like a real one:

  - the controller is a ROUTER with no radios of its own, so anything keyed on
    device_type = 'wireless_ap' misses it
  - CAP interfaces carry NULL frequency, SSID and band, because the controller owns
    the configuration — the exact condition that removed them from Channel Usage
  - the controller mirrors every CAP interface locally, so a CAP's radio MAC
    legitimately appears on two devices — the condition behind the misattribution
  - channels exist only as "<freq>/<phy>/<control-positions>", never a plain number
  - the radios are arranged to produce one partial overlap and one co-channel pair,
    so interference classification has something real to get wrong

Running it against v0.23.7 confirms the fix shipped blind two commits ago actually
works: six managed radios now group under the controller, the controller appears in
the location selector, the standalone group holds only the genuinely standalone AP,
5680/ax/eCee/D resolves to 80 MHz, client counts come from the controller where the
CAP rows read zero, and the controller's mirror interfaces do not double-count.

Documented in docs/architecture.md, including the point that when a report arrives
with device output attached, that output is the most valuable thing in it and
belongs in the fixture.

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

docs/architecture.md

@@ -109,6 +109,43 @@ Statements are written to be safe to re-run — `CREATE TABLE IF NOT EXISTS`,
 `ADD COLUMN IF NOT EXISTS`, and guarded constraint swaps — so upgrading is just starting
 the new image.
 
+## Developing against hardware you do not have
+
+Two bugs shipped in v0.23.5 and v0.23.6 because CAPsMAN code was written and
+"verified" against a fleet containing no CAPsMAN. Neither was catchable by unit
+tests: both lived in SQL — a join that could never match, and a `WHERE` clause that
+filtered out every managed radio before the analysis ran.
+
+`scripts/seed-capsman-fixture.sql` reproduces the shape of a real deployment so
+those paths can be exercised locally against the actual endpoints:
+
+```bash
+docker compose exec -T postgres psql -U mikrotik -d mikrotik_manager \
+  -q -f - < scripts/seed-capsman-fixture.sql
+
+# ... work, hit /api/wireless/rf/channels, /api/wireless/capsman ...
+
+docker compose exec -T postgres psql -U mikrotik -d mikrotik_manager \
+  -q -f - < scripts/seed-capsman-fixture-clean.sql
+```
+
+The fixture is deliberately awkward in the ways real deployments are:
+
+- the controller is a **router** with no radios of its own, so anything keyed on
+  `device_type = 'wireless_ap'` misses it
+- CAP interfaces carry **NULL frequency, SSID and band**, because the controller owns
+  the configuration — code that requires a frequency silently drops them
+- the controller **mirrors every CAP interface locally**, so a CAP's radio MAC
+  legitimately appears on two devices
+- channels appear only in RouterOS's `<freq>/<phy>/<control-positions>` form, never
+  as a plain number
+- the radios are arranged to produce one partial overlap and one co-channel pair, so
+  interference classification has something real to get wrong
+
+Everything it creates is prefixed `fixture-`. Add to it rather than working from
+assumptions whenever a report arrives with device output attached — that output is
+the most valuable thing in the issue.
+
 ## Before you push
 
 `scripts/ci-preflight.sh` runs the same gates as CI — lint, type-check, build, tests and