fix: a login that times out now names multi-byte path hashing (#278, #280)

Two reports of remote management, telemetry and ping all failing against a
repeater or room server while the same operations work from other MeshCore
clients, with no error anywhere: "Logging in..." disappears and nothing happens.

Multi-byte path hashing fails exactly like that. sendFloodScoped() stamps
path_hash_mode + 1 bytes of repeater hash onto unicast floods, which is the
login / status / telemetry / ack path specifically, while channel traffic takes
a different overload. A repeater that predates the feature, or does not
implement it, drops 2- and 3-byte-hash packets SILENTLY, so the request never
arrives and nothing on either side reports a failure. randelreiss said outright
he is running 3-byte hashes (#280).

It defaults to 1 byte and is opt-in, so this is behaving as designed. What is
not reasonable is that someone who turned it on has no way to connect that
choice to "remote management stopped working" weeks later. The timeout already
had the operator's attention and was spending it on password, server and clock;
it now names the path-hash setting and where to change it when the setting is
not on its default.

Does not change any send behaviour. This is diagnosis, not a fix for the drop
itself, and it is deliberately worded as a thing to try rather than a verdict:
neither reporter has confirmed the cause yet.

All 8 S3 boards build.

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

src/ui-touch/UITask.cpp

@@ -15449,9 +15449,23 @@ static void loginWaitTimeoutCb(lv_timer_t* t) {
   time_t tt = (time_t)the_mesh.getRTCClock()->getCurrentTime();
   struct tm tmv;
   if (localtime_r(&tt, &tmv)) strftime(when, sizeof when, "%H:%M %d %b", &tmv);
-  char msg[120];
-  snprintf(msg, sizeof msg, TR("No reply. Check password, server,\nor device clock (device: %s)"), when);
-  g_lv.task->showAlert(msg, 4500);
+  char msg[160];
+  // Multi-byte path hashing is the one setting that makes a login fail EXACTLY like
+  // this: a repeater that predates it, or does not implement it, silently drops 2- and
+  // 3-byte-hash packets, so the request never arrives and no error is ever generated
+  // anywhere. It is opt-in and defaults to 1 byte, but someone who turned it on has no
+  // way to connect that choice to "remote management stopped working" — reported twice
+  // (#278, #280), once explicitly while running 3-byte hashes. Name it here, where the
+  // operator is already looking, rather than leaving them to find it in Settings.
+  const uint8_t phm = the_mesh.getNodePrefs() ? the_mesh.getNodePrefs()->path_hash_mode : 0;
+  if (phm > 0) {
+    snprintf(msg, sizeof msg,
+             TR("No reply. Path hash is %u bytes;\nolder repeaters drop those.\nTry 1 byte (Settings > Radio & Mesh)"),
+             (unsigned)(phm + 1));
+  } else {
+    snprintf(msg, sizeof msg, TR("No reply. Check password, server,\nor device clock (device: %s)"), when);
+  }
+  g_lv.task->showAlert(msg, 5000);
 }
 static void loginWaitArm(LoginWaitKind kind) {
   loginWaitCancel();