v0.29.1: lanresolver restarts dnsmasq on change (SIGHUP doesn't re-read config)

After a guest DHCP IP move, the split-horizon resolver kept serving the old IP:
the drop-in (address=/domain/ip) updated but 'systemctl reload dnsmasq' (SIGHUP)
does NOT re-read /etc/dnsmasq.d config — only /etc/hosts + cache. Changed
reload() -> restartDnsmasq() so address= changes actually take effect.

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

CHANGELOG.md

@@ -3,6 +3,20 @@
 All notable changes to **felhom-agent** are recorded here. Update on every code
 change that gets pushed.
 
+## v0.29.1 — lanresolver: RESTART dnsmasq on change (not reload) — fixes stale split-horizon IP (2026-06-13)
+
+**Bug:** after a guest's DHCP IP moved (e.g. the v0.29.0 9201 re-provision: .151 → .141), the LAN
+split-horizon resolver kept answering the OLD IP, so LAN clients (via Pi-hole's conditional forward to
+the host dnsmasq) resolved `*.demo-felhom.eu` to the dead IP. Root cause: `lanresolver.Manager` updated
+the per-customer drop-in (`address=/<domain>/<ip>`) correctly but then ran `systemctl reload dnsmasq`
+(SIGHUP) — and **dnsmasq's SIGHUP does NOT re-read its config files** (`/etc/dnsmasq.d/*.conf`); it only
+clears the cache + re-reads `/etc/hosts`/addn-hosts. So the changed `address=` directive never took
+effect until a restart. **Fix:** `reload()` → `restartDnsmasq()` (`systemctl restart dnsmasq`) for every
+config-drop-in change (ReconcileGuest IP change, EnsureDnsmasq base change, Remove/decommission). Restart
+is sub-second and the records carry local-ttl 0, so downstream forwarders don't cache a stale answer.
+(Live: after the fix + a one-time host dnsmasq restart + a Pi-hole cache flush, `*.demo-felhom.eu`
+resolves to the live guest IP again; future IP moves now self-heal on the loop's next tick.)
+
 ## v0.29.0 — OS / Docker-data storage split: golden + provision (2026-06-13)
 
 Phase 1 of the storage-split slice (Phase 2 = felhom-controller v0.58.0 prevention layer). The