fix(ui): Admin password change didn't update the saved login copy

Same fix as hotfix/admin-login-timeout (05609019). Tools > Admin >
System > "Admin password" changes the remote's admin credential but
never updated this device's saved copy, so the next login retried the
password just replaced -- likely the actual trigger behind the
"stuck on Logging in..." report. Parses CommonCLI's "password now: <v>"
success echo and saves that as the new on-device password.

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

examples/companion_radio/ui-new/AdminScreen.h

@@ -410,6 +410,23 @@ public:
       openValueKb(trimmed);   // _pending_set_prefix is already set from activateField()
       return;
     }
+    // The "Admin password" row (SYSTEM_FIELDS, set-only) just changed the
+    // remote's own admin credential -- CommonCLI::handleCommand() always
+    // echoes it back as "password now: <value>" (see src/helpers/CommonCLI.cpp),
+    // truncation and all, so parsing that confirms the exact value now
+    // required to log back in. Without this, our saved password goes stale
+    // the instant this command succeeds, guaranteeing the next login attempt
+    // fails (see the LOGIN-phase timeout fix above for what that used to look
+    // like: a permanent "Logging in..." hang with a stale saved password).
+    static const char PW_ECHO_PREFIX[] = "password now: ";
+    if (!strncmp(text, PW_ECHO_PREFIX, sizeof(PW_ECHO_PREFIX) - 1)) {
+      char newpw[32];
+      strncpy(newpw, text + sizeof(PW_ECHO_PREFIX) - 1, sizeof(newpw) - 1);
+      newpw[sizeof(newpw) - 1] = '\0';
+      size_t n = strlen(newpw);
+      while (n > 0 && (newpw[n-1] == '\n' || newpw[n-1] == '\r' || newpw[n-1] == ' ')) newpw[--n] = '\0';
+      the_mesh.saveRoomPassword(_target.id.pub_key, newpw);
+    }
     strncpy(_reply_text, text, sizeof(_reply_text) - 1);
     _reply_text[sizeof(_reply_text) - 1] = '\0';
     _reply_view.begin();

release-notes.md

@@ -14,6 +14,7 @@
 
 - **DM/room replies sometimes didn't show who they were addressed to, and room messages could wrap incorrectly.** The reply-prefix (`@[nick] `) was being stripped at the wrong point for room posts and DMs feeding the fullscreen message view, so a DM reply's "To:" header could go missing while a room reply showed the raw `@[nick] ` marker as literal message text; a related mismatch meant the history list's scrollbar/box-height sizing pass wrapped room messages with their sender name still attached, disagreeing with the actual rendered text.
 - **Tools › Admin login could get stuck on "Logging in..." forever** if the remote node never sent back a reply — most commonly after its admin/room password was changed, since the on-device UI auto-retries the old saved password with no timeout to fall back on. It now gives up after the same estimated-timeout window the rest of Admin's commands use, forgets the stale saved password, and returns you to the picker to try again with the new one.
+- **Changing a remote's admin password from Tools › Admin › System didn't update this device's own saved copy** — the very next login attempt to that node retried the password you'd just replaced, hitting the "stuck on Logging in…" case above. The confirmation the remote echoes back is now saved as the new on-device password to match.
 
 ---