fix(ui): Admin login could hang forever on "Logging in..."

AdminScreen's LOGIN phase had no timeout, unlike its COMMAND phase
(_cmd_deadline_ms). If a login reply never arrived -- most commonly a
saved password gone stale after the remote node's password changed,
silently dropped instead of nacked -- the screen stayed stuck with only
a manual Cancel to escape.

sendRoomLogin() now returns the same est_timeout sendAdminCommand()
already exposes; AdminScreen uses it to arm a deadline (poll(),
mirroring the COMMAND-phase pattern) that forgets the stale password
and returns to the picker on expiry, same as an explicit login
rejection already does.

Same fix as hotfix/admin-login-timeout (23f43cac), split out of this
branch's other in-progress work.

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

examples/companion_radio/ui-new/MessagesScreen.h

@@ -722,7 +722,9 @@ public:
   void startRoomLogin(const char* password) {
     strncpy(_login_pw, password, sizeof(_login_pw) - 1);
     _login_pw[sizeof(_login_pw) - 1] = 0;
-    bool sent = the_mesh.sendRoomLogin(_sel_contact, password);
+    uint32_t est_timeout = 0;   // this screen's login isn't a blocking wait (see
+                                // onRoomLoginResult() below), so no deadline needed
+    bool sent = the_mesh.sendRoomLogin(_sel_contact, password, est_timeout);
     _task->showAlert(sent ? "Logging in..." : "Login failed", sent ? 1000 : 1500);
   }