长轮询客户端超时 120 -> 180 秒（实测出现 126.6 秒的长尾）

relay-stability 跑了 30 次真实长轮询，第 1 次耗时 126604ms：

    服务端 hold 是 60 秒
    剩下 66 秒全是网络停顿（4G 抖动 + 重传退避）
    而客户端超时写的是 120000ms
    -> 126.6 > 120，那次会被**误判成失败**，尽管服务端已经正常返回

其余 29 次都是 61~62 秒，很正常。不是 hold 太长，是网络尾巴太长。

为什么放宽超时而不是缩短 hold：
  A. hold 缩到 45 秒、超时保持 120 -> 最坏 111 秒，安全
     但请求数多 33%，而每次请求都要吃隧道 1~2 秒开销
  B. hold 保持 60 秒、超时放宽到 180 -> 最坏 180 秒，安全
选 B —— 这条链路的根本问题是丢包抖动，**请求越少越不容易撞上**。
放宽超时只是"别把慢但成功的请求冤枉掉"，不增加任何请求。

客户端已有"连续失败 3 次才判离线"（OFFLINE_AFTER=3），
所以偶尔一次长等待不会让界面闪"已断开"。

超时余量的演进（全是实测逼出来的）：
  90 秒  -> 实测 93589ms  不够
  120 秒 -> 实测 126604ms 不够
  180 秒 -> 60 hold + 120 余量

两边同步改：
  windows/lanremote/relay.py                     POLL_TIMEOUT 120 -> 180
  android .../RelayTransport.java                POLL_TIMEOUT_MS 120000 -> 180000
（Java 侧确认 setConnectTimeout 另有 15 秒上限、setReadTimeout 吃这个值，
  没有别的超时会先把请求掐掉。）

android/src/com/lanremote/watch/RelayTransport.java

@@ -41,13 +41,15 @@ public class RelayTransport implements Transport {
      *
      * <p>必须显著大于服务端的 hold 时间，否则会在服务端正常返回
      * 之前自己先超时 —— 那就变成"每次轮询都失败"了。
-     * 120 秒 = 60（hold） + 60（网络余量）。
      *
-     * <p>余量给这么大是因为实测出现过一次 93589ms 的长尾
-     * （4G 丢包触发 TCP 重传退避）。设 90 秒会把那次
-     * 其实成功的请求误判成失败。
+     * <p>180 秒 = 60（hold） + 120（网络余量）。
+     * 余量一直在加大，因为实测的长尾一直在刷新：
+     * 90 秒时实测到 93589ms，120 秒时实测到 126604ms
+     * （30 次里 1 次，其余都是 61~62 秒）。
+     * 4G 丢包触发的重传退避能拖出一分钟以上的停顿，这是链路特性。
+     * 放宽超时只是"别把慢但成功的请求冤枉掉"，不增加请求数。
      */
-    private static final int POLL_TIMEOUT_MS = 120000;
+    private static final int POLL_TIMEOUT_MS = 180000;
     /** 发送/接收的单次请求超时 */
     private static final int SEND_TIMEOUT_MS = 30000;
     /** 网络出错后的退避 */