v0.2.0

Added

• First-boot setup access point. While a device is unclaimed (setup not
  complete) meshd now brings up a known, label-printable WiFi AP
  (OMM-Setup-<last4-of-node-id>) on a small static network
  (192.168.254.1/24) serving its open management API, so a companion app can
  reach an out-of-the-box node before it has joined any network. The AP is torn
  down automatically once onboarding completes. Open by default; set
  MESHD_SETUP_AP_KEY for WPA2, MESHD_SETUP_AP_RADIO to choose the radio, or
  MESHD_SETUP_AP=0 to disable (e.g. a radio-less wired controller). New
  internal/setupap package; uci.Client gained SetSection/Delete. Covered
  by a real-OpenWrt-container e2e (TestSetupAPLifecycleE2E) asserting the uci
  sections appear on boot and are removed once onboarding completes.
• Companion onboarding app. The Vue frontend now also builds as a
  cross-platform companion app (Capacitor: Android/iOS/desktop), whose first goal
  is to make adding a node a few-tap flow. It discovers controllers on the LAN
  (native mDNS _mesh._tcp, falling back to the daemon's /scan), can target a
  specific device over the LAN (an unclaimed node's setup-AP address or a
  controller's announced URL), and guides adding a node end to end (/onboard):
  read the device's setup label (QR — OMM-JSON, the WIFI: standard, or a bare
  SSID), join its setup AP, reach it, request enrollment (/enroll/join), and
  confirm adoption — including signing in to a split-mode controller (LuCI
  session.login over /ubus) when its management API is localhost-bound. The
  native capabilities (mDNS / WiFi-join / QR scan) sit behind a bridge that is a
  no-op in the browser, so the existing PWA is unchanged. See the design spec in
  doc/companion-app.md.
• Guided onboarding wizard + wireless-only enrollment. The onboarding flow is
  now a three-page wizard — choose Home → choose device → confirm — that
  auto-progresses between steps and adopts the node in the background once the
  app holds a controller client, with no manual approve step. A node without an
  Ethernet uplink can now be enrolled over WiFi: meshd gains
  POST /setup/uplink (unclaimed devices only) which brings up a station
  wifi-iface + DHCP-client network from supplied home-WiFi credentials so the
  node can reach its controller, torn down with the setup AP once onboarding
  completes (internal/setupap EnableUplink). On Android the wizard offers a
  setup-AP picker (OMM-Setup-*); iOS/web keep the QR/manual path. Covered by a
  real-OpenWrt-container e2e (TestSetupUplinkE2E). See §13–§14 of
  doc/companion-app.md.
• Companion-app local dev workflow. scripts/run-dev-stack.sh plus a Vite
  dev-server proxy for all meshd REST endpoints make it possible to drive the
  companion app against a local meshd for manual enrollment testing.
  MESHD_DEV_CORS (development only) lets a cross-origin app call the management
  API directly, logging a warning when enabled. The onboarding wizard can also
  target an explicit node URL (e.g. a wired node) instead of the setup-AP default.
• Companion app packaging. The frontend now builds as native Android/iOS apps
  (Capacitor) with the QR (@capacitor-mlkit/barcode-scanning) and WiFi-join
  (@falconeta/capacitor-wifi-connect) plugins wired in; desktop ships as the
  installable PWA. Native platform projects are generated on a dev machine
  (gitignored) via npm run cap:*. See the build steps, required permissions and
  the on-device verification matrix in
  doc/companion-app-packaging.md. (Native mDNS
  awaits a Capacitor-8 plugin; until then discovery falls back to the daemon's
  /scan.)
• Release publishes the Android companion app. A v* tag now also builds
  and (with an ANDROID_KEYSTORE_BASE64 secret) signs the Android APK and
  attaches it to the GitHub Release. The job is decoupled from the meshd package
  jobs, so it never blocks the OpenWrt release; iOS (App Store/TestFlight) and
  desktop (the installable PWA) are out of scope. Required secrets are listed in
  doc/companion-app-packaging.md.
• End-to-end test for the LuCI integration. TestLuCIWorkflowE2E boots a
  real OpenWrt userland with the built meshd + luci-app-meshd packages and
  the full LuCI stack (ubusd + rpcd + uhttpd), then drives the operator
  workflows over the authenticated /ubus endpoint exactly as the PWA does:
  the ACL gate, node enrollment + adopt, the Home/profile lifecycle, and a
  wireless client device surfacing through the topology read. Runs in the e2e
  CI job; see doc/luci-integration-testing.md.

Fixed

• Creating a Home through the setup wizard failed with ubus error 5.
  Selecting a freshly created Home applied its (non-existent) profile, and the
  API treated the missing profile as a fatal 500 — even though meshd's own
  auto-select already treats it as non-fatal. Selecting a Home with no profile
  yet now succeeds; only real apply failures error.
• Opaque ubus error 5 from the LuCI Mesh Manager. The rpcd plugin used
  curl -f, which discarded meshd's JSON error body on any HTTP error, leaving
  rpcd to report a bare NO_DATA (5). The plugin now passes meshd's
  {"error": …} body back through so the PWA shows the real reason.
• Local meshd builds now run on OpenWrt. scripts/build.sh defaults to
  CGO_ENABLED=0, producing a statically-linked binary; the previous dynamic
  (glibc) build failed on OpenWrt's musl userland with
  can't execute '/usr/bin/meshd': No such file or directory.
• Onboarding wizard's default node client. A function-typed prop default was
  treated as a factory, so the default client was a function rather than a
  client; the wizard now reaches the node without an explicit createClient.