fix(ui): a stale login reply for a different node could be accepted

Same fix as hotfix/admin-login-timeout (96b44460). AdminScreen's only
guard was "_phase == LOGIN" (true for any node sat at the login
screen), not that the reply actually named _target. Now also checks
pub_key against _target.id.pub_key.

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

examples/companion_radio/ui-new/AdminScreen.h

@@ -357,7 +357,16 @@ public:
   // Async result of the on-device login, routed here from UITask::onRoomLoginResult()
   // only while this screen is current (see that routing for why).
   void onRoomLoginResult(const uint8_t* pub_key, bool success, uint8_t permissions) {
-    if (_phase != LOGIN) return;   // stale/unrelated result
+    // Being in LOGIN phase isn't enough on its own -- this only confirms *some*
+    // login is in flight for *this screen*, not that this particular reply is
+    // for _target. UITask::onRoomLoginResult() dispatches by whichever screen
+    // is current, not by who sent the request, so e.g. a slow MessagesScreen
+    // login reply arriving while the user has since opened Admin on a
+    // *different*, password-less node (still sat at the blank LOGIN keyboard,
+    // so _phase == LOGIN here too) would otherwise be accepted as if it were
+    // this node's own login -- flipping _admin_ok/_phase to COMMAND for
+    // _target without ever actually authenticating with it.
+    if (_phase != LOGIN || memcmp(_target.id.pub_key, pub_key, 4) != 0) return;   // stale/unrelated result
     _login_waiting = false;
     if (success && (permissions & PERM_ACL_ROLE_MASK) == PERM_ACL_ADMIN) {
       memcpy(_admin_ok_prefix, pub_key, 4);

release-notes.md

@@ -16,6 +16,7 @@
 - **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.
 - **A slow-to-arrive Admin login reply, after you'd already given up on it (Cancel or the new timeout above), could get delivered to whatever screen you'd since moved to and silently overwrite your saved password for that node with unrelated data.** Giving up on a login now also stops tracking it mesh-side, so a late reply is simply dropped instead of misrouted.
+- **Opening Admin on a second, password-less node while an earlier room/repeater login elsewhere was still in flight could wrongly show you as logged in as admin on the new node** — a reply meant for the earlier login was accepted as this node's own since both merely looked like "a login is pending," without checking it actually named this node. Now checked.
 
 ---