Add DHCP reservations to the web UI, split out a fast webui test

The DHCP page edits the reservations per LAN (checked like the module's
assertions) and offers active clients for reservation. The web UI checks
that need no installed system moved from apply.nix into webui.nix (one
node, under a minute); apply.nix shares one apply for the pool change and
a reservation.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AeFqV9dZrK6nipHkPfyM4F

DEVELOPING.md

@@ -45,8 +45,17 @@ runs `router-apply` on the router (building a NixOS system there takes about a
 minute) or waits for a rollback timer. A source change rebuilds the systems
 again on the host. So:
 
+Measured (one at a time): `webui` 45 s, `basic` 107 s, `onestick` 77 s; the
+ones that install and rebuild on the device are the slow ones: `apply` and
+`update` several minutes, `setup` 11 minutes (three installs).
+
 - Try a change with `webui-dev` or `fast` first; run a VM test only to confirm.
-- Run only the test for what you changed: `update` for `router-update` and
-  the Update page, `setup` for `router-setup`, `apply` for the settings and
-  the web UI, `basic` for the firewall and DHCP.
+- A change to the web UI only needs `webui` (a single node, no install).
+  `apply`, `setup` and `update` are for what an installed router does:
+  on-device builds, rollback, `router-setup`, `router-update`. Run them
+  before a release or when you touched those, not after every UI edit.
+- Nix does not rerun a test whose inputs did not change, so `--all` after a
+  small change is cheaper than it looks, except that the web UI is part of
+  every installed system: any change to it invalidates `apply`, `setup`
+  and `update`.
 - Use `-i` to iterate on a test script.