dev:web watch loop: ~7G memory baseline, unbounded growth to 12.5G over 22h, and V8-OOM crash loop under memory pressure (no start limit, no memory cap)

[sharework-ai]

环境：Ubuntu 26.10, kernel 7.0.0-38, node v24.21.0, dsh @ 687f282 (0.2.1-rc.2), 21G RAM + 8G swap, k3s co-located. Unit: pnpm run dev:web --skip-build（即 tsx scripts/dev-web.ts --poll，tsc/tsdown/vite 三 watcher + dsh web）作为 systemd --user 常驻服务，无人操作。
oomdump.txt

现象（journalctl/systemd 记账）：
▎ 1. 每次冷启动 cgroup Mem peak 即 5.8-7.2G（30 秒内）；--poll 模式空闲时持续消耗 ~35% 单核（22h47m 消耗 7h56m CPU）。
▎ 2. 逐次启动 peak 单调走高：7.2G → 7.4G → 7.6G → 7.7G → 12.5G（22h47m run，swap peak 896.2M）。
▎ 3. 主机内存压力下 tsc watch 在 ~55 秒内撞 V8 4G 默认堆顶死亡：Ineffective mark-compacts near heap limit ... JavaScript heap out of memory（Mark-Compact 4090MB）。Restart=on-failure + RestartSec=5 且无 StartLimitBurst/MemoryHigh → 连续 9 次重启、每次再冲 6.7-7.1G 波峰，把整机推进 global OOM，同机 k3s pods 被内核连环击杀（load 84，swap 100%）。
▎ 4. 被杀后再启动的 tsc 报出此前不存在的 43 个类型错，疑似 SIGKILL 打断 emit 污染了 lib/types 增量状态，此后每次冷启动都更烧内存，形成自持循环。
▎
▎ 期望：watch 循环的内存行为应有界（tsc heap cap 或分阶段限流）、对 stage 被杀有快速失败而非无限重启、文档给出无人值守运行的建议配置（systemd MemoryHigh/StartLimitBurst、NODE_OPTIONS=--max-old-space-size）。可附上 journalctl --user -u 的 Consumed ... memory peak 序列作为复现参照。

善后建议

1. 常驻换模式：24/7 服务不该跑 watcher——scripts/dsh-web.sh install --serve（start:web，纯 serve 无 watcher），要改代码时再切回 dev 模式。这是最直接的根治。
2. 若坚持 dev 模式常驻：给 unit 加 MemoryHigh=6G（软顶）+ StartLimitIntervalSec=300/StartLimitBurst=3，并给 tsc 设 NODE_OPTIONS=--max-old-space-size=3072。我可以帮你改 dsh-web.sh 的 unit_content。
3. 恢复前先全量 pnpm run build 清掉被污染的 lib/types，再上 --fast。