Dingtian web password: set the admin's chosen password, verified

Fix two bugs found running the real assign flow: the saved web password
didn't match the device (login stayed admin/admin), and the UDP2 warning
never reached the admin.

Web password:
- Split the conflated field into webPassword (the DESIRED login; blank ->
  auto-generate) and webPasswordCurrent (the device's EXISTING password used
  as the old cred, default admin). Before, an admin typing a desired password
  made harden send it as the old cred -> rotation failed -> but the DB still
  saved the typed value, so it claimed a password the device never accepted.
- harden() now rotates current -> desired, VERIFIES by re-authenticating with
  the new password, and only returns secrets.webPassword on success (else a
  warning, nothing saved). Stores webPasswordCurrent for future re-runs.
- assign strips the typed webPassword/webPasswordCurrent and persists only the
  verified secret -- the DB never claims an unapplied password.

Warnings to the UI:
- assignDevice returns warnings[]; SetupWizard shows them in an amber
  "saved, but action needed" banner per category. This is how the admin learns
  the firmware wouldn't disable UDP2 (finish in the device web UI).

Verified on hardware: after harden the device rejects admin/admin and accepts
the chosen password; the UDP2 warning surfaces.

wiki/entities/dingtian-relay.md

@@ -115,6 +115,17 @@ On assign the driver runs `harden()` (the [[device-registry|HardenableDevice]] c
 > UDP2 off in the device web UI. Verified: after the web-UI disable, the `"11"` attack gets no
 > reply and the relay stays off, while authenticated binary control/status still work.
 
+> 🔑 **Web-login model (bug fixed).** The login set has TWO distinct config keys:
+> `webPassword` = the password the admin WANTS (blank → harden generates a random one), and
+> `webPasswordCurrent` = the device's EXISTING password (the old cred `userset.cgi` checks;
+> defaults to `admin`). The original code conflated them — an admin typing a *desired* password
+> made harden send it as the *old* cred, the rotation failed, yet the DB still saved the typed
+> value: **the DB claimed a password the device never accepted (login stayed admin/admin).**
+> Fix: harden now rotates `current → desired`, **verifies** by re-authenticating with the new
+> password, and only then returns `secrets.webPassword`; assign strips the typed inputs and
+> persists only the verified value (else a warning, no save). Verified on hardware: device
+> rejects `admin/admin` (`&2&`) and accepts the chosen password (`&0&`) after harden.
+>
 > ⚠️ **The device CGI API is UNAUTHENTICATED.** Verified on hardware: `GET /api/v2/config.cgi`,
 > `/`, and even `/userset.cgi` all return **200 with no credentials**. The `admin`/`admin` login
 > gates only the interactive **browser UI** — the CGI control plane (read/write full config, fire

wiki/log.md

@@ -274,3 +274,17 @@ guarantee. Recorded in [[dingtian-relay]] (new Hardening section).
 - INCIDENT: probing default.cgi factory-reset the bench device (now at 192.168.1.100, defaults).
   Re-provisioning is the ADMIN's job via First-run setup (app must not hardcode site IPs).
 - Updated [[append-only-event-chain]], [[dingtian-relay]].
+
+## [2026-06-15] fix | Dingtian web-password: desired-vs-current split + verify + UI warnings
+- BUG (found in real assign): admin typed a web password; harden used it as the OLD cred, rotation
+  failed silently, DB saved the typed value but device login stayed admin/admin. Also UDP2 warning
+  never reached the admin (frontend discarded the assign response).
+- FIX: split config into webPassword (desired; blank→random) and webPasswordCurrent (existing old
+  cred, default admin). harden() rotates current→desired, VERIFIES by re-auth with the new pw, and
+  only returns secrets.webPassword on success (else warning, no save). assign strips typed
+  webPassword/webPasswordCurrent and persists only verified secrets.
+- SetupWizard now shows assign-response warnings (amber banner, per category) — closes the
+  feedback loop for the UDP2-can't-disable case.
+- Verified on hardware (192.168.1.100): harden set login to a chosen pw; device then rejects
+  admin/admin (&2&) and accepts the chosen pw (&0&). UDP2 warning surfaced as designed.
+- Updated [[dingtian-relay]].