fix(wireless): read CAPsMAN radio channels from the controller (v0.23.7-beta)

Follow-ups on #97 and #106, both reported against the releases they shipped in.

#97 — managed radios were missing from Channel Usage entirely
  The query required wireless_interfaces.frequency > 0. A CAPsMAN-managed access
  point stores no frequency of its own: the controller owns the channel, and the
  AP's own rows carry nulls. Every managed radio was therefore filtered out before
  analysis ran, which is why the reporter saw all access points collapse into
  "Standalone" and a controller vanish from the selector — the group had no
  surviving radios to name it.

  The channel now comes from capsman_radios.current_channel where present, parsed
  from RouterOS's `<freq>/<phy>/<control-positions>` form. The control letters give
  a precise operating width — Ce is 40 MHz, Ceee is 80 — rather than the capability
  list a width field reports. Client counts prefer the controller's per-radio figure
  for the same reason.

  Verified only by unit test here, since we run no CAPsMAN. The local fleet still
  reports its two standalone radios unchanged.

#106 — the setting had no way to change it
  maps_enabled shipped without a control, which made it a setting in name only.
  Added under Settings, with the reasoning stated: tiles and geocoding are outbound
  requests to a third party, and the address entered is sent to them.

  Also removed the "map display is off" placeholder. The reporter pointed out it can
  never appear in the environment it was written for — with maps disabled from the
  start no coordinates are ever geocoded, so the block was dead code.

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

backend/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mikrotik-manager-backend",
-  "version": "0.23.6-beta",
+  "version": "0.23.7-beta",
   "description": "Mikrotik Network Management Platform - Backend API",
   "main": "dist/index.js",
   "scripts": {