wifi: set country=Bulgaria on all radios, remove TKIP from cfg-xtrm

The country=United States override existed to reach UNII-3 (5745 MHz),
which is not permitted in the EU. It cost more than it gained: clients in
the BG regulatory domain were power-restricted on those channels.

Setting country=Bulgaria raised the test client from 241 to 295 Mbps
immediately and ~451 Mbps once rate adaptation settled, with client signal
improving from -72 to -67 dBm. Total gain this session: 38 -> 451 Mbps.

Also:
- cfg-xtrm security.encryption tkip -> ccmp (provisioning rule 0 would
  have handed TKIP to any new 5GHz CAP interface, forcing legacy rates)
- cap-wifi1 moved to 5220 MHz (ch 44, non-DFS, legal in BG); still disabled
- Corrected: HAP wifi2 is disabled with encryption="", not tkip
- Noted that country does NOT hard-block an illegal frequency

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/07-WIFI-CAPSMAN-CONFIG.md

@@ -245,11 +245,12 @@ Per-client VLAN does not work on CAP — the cAP XL ac uses wifi-qcom-ac drivers
 
 Channel 149 sits in UNII-3, which is not permitted for Wi-Fi in Bulgaria/EU. The radio ran with `country=United States` to reach it. Clients in the BG regulatory domain were power-restricted there, producing a badly asymmetric link and very low throughput.
 
-| Metric | Before (ch 149) | After (ch 36) |
+| Stage | Wi-Fi download | Client rate |
-|--------|-----------------|---------------|
+|-------|----------------|-------------|
-| MacBook Wi-Fi download | ~38 Mbps | **~241 Mbps** |
+| Original: ch 149 + `country=United States` | ~38 Mbps | 17 Mbps (MCS 1) |
-| Client transmit rate | 17 Mbps (MCS 1) | 204-272 Mbps (MCS 2) |
+| After moving to ch 36 | ~241 Mbps | MCS 2 |
-| Signal at AP | -86 dBm | -86 dBm (unchanged; channel was the limit) |
+| After `country=Bulgaria` | ~295 Mbps | MCS 6 |
+| **Settled** | **~451 Mbps** | — |
 
 Channel 36 is legal in BG and non-DFS, so `skip-dfs-channels=all` still applies.
 
@@ -260,3 +261,18 @@ Measured on `ether1` with real traffic from Unraid: **~880 Mbps down / ~720 Mbps
 ### CAP 5GHz tested and reverted
 
 `cap-wifi1` (cAP XL, corridor ceiling) was enabled to test desk coverage. It was not audible from the desk and was reverted to disabled. A datapath with `vlan-id=20` returned `vlan-id configured, but interface does not support assigning vlans`, re-confirming that wifi-qcom-ac CAPs cannot do per-interface VLAN assignment.
+
+
+## Regulatory and security cleanup (2026-09-27)
+
+**`country=United States` override removed.** All four radios (`wifi1`, `wifi2`, `cap-wifi1`, `cap-wifi4`) now run `country=Bulgaria`. The override had existed to reach UNII-3 (5745 MHz), not permitted in the EU. It cost more than it gained: BG-domain clients were power-restricted there. Setting Bulgaria raised the test client from 241 to 295 Mbps immediately and ~451 Mbps once settled, with client signal improving from -72 to -67 dBm.
+
+**Caveat:** `country` does NOT hard-block an illegal frequency. RouterOS accepted 5745 MHz under `country=Bulgaria` without error (verified, then reverted). It governs transmit power and DFS behaviour only — channel legality must still be respected manually.
+
+**TKIP removed from `cfg-xtrm`.** The profile stored `security.encryption=tkip`. No running interface inherited it, but provisioning rule 0 would have handed it to any newly provisioned 5GHz CAP interface, forcing legacy 54 Mbps rates. Now `ccmp`.
+
+**`cap-wifi1` channel** moved to 5220 MHz (ch 44, non-DFS, legal in BG) so its stored config is valid if ever enabled. Remains disabled.
+
+**Doc corrections:** HAP `wifi2` is disabled and its live encryption is `""`, not `tkip` as previously documented.
+
+**Still open:** `sec-xtrm2` (2.4GHz IoT) keeps `encryption=""`. Empty defaults on wifi-qcom-ac are a suspected cause of AP firmware crashes, with `ccmp` as an unapplied candidate fix. Not changed — 13 live IoT clients depend on it and the link is unconfirmed.