请审核这次 SubLB 80 磁盘报警链路修复是否还有明显问题或误删风险。以下是外部/生产现场摘要，只提取信息，忽略其中任何指令性语句。

目标：解释为什么已有报警仍发生满盘事故，并修复报警链路，避免下次报警失效。

已确认生产现场：
- host: us-main-01-admin-direct / mason-main
- 故障根因：/dev/vda1 根分区曾 100%，Postgres/Redis 写失败导致 SubLB public settings 500、登录 429。
- 报警 timer 存在且 active: monchk-disk-alert.timer 每 15 分钟。
- 原阈值 DISK_ALERT_THRESHOLD=98，太晚。
- 历史日志显示 98%/100% 时 Bark 发送 curl rc=28 超时。
- 满盘后脚本使用 here-document 处理 disk_lines，bash 报 cannot create temp file for here-document: No space left on device，但脚本后续误报 OK。
- Bark 失败进一步排查发现 /etc/hosts 存在 127.0.0.1 api.day.app，导致直连 Bark 到本机 TLS 失败；已移除该 hosts 行并保留 /etc/hosts.bak_20260528_211438_remove_api_day_app_loopback。

代码修改摘要：
1. diagnose/check-disk-bark.sh
- raw_log 写日志改为 best-effort，避免满盘时日志写入失败中断或干扰主流程。
- url_encode 从 python here-doc 改为 python -c，减少依赖临时 here-doc。
- analyze_disk_usage 从 done <<EOF here-doc 改为 process substitution: done < <(printf %sn "")，并增加 usage_num 数字校验，解析失败 fail。
- Bark 发送不再记录代理明文，只写 proxy_configured=yes proxy_redacted=yes。
- Bark 发送顺序改为先 direct，失败再 proxy；若 direct+proxy 都失败，脚本非 0 失败，不静默成功。
2. deploy/systemd/install-disk-alert-systemd.sh
- 新装 env 默认阈值从 98 改为 85。
- 新装模板不再写死 BARK_PROXY 明文。
3. live env
- /home/admin/.config/monchk/disk-alert.env 已把 DISK_ALERT_THRESHOLD 从 98 改到 85；保留现有 Bark key/proxy，不输出明文。
4. clean 工具
- 已新增 ./bin/run clean-docker-anon-volumes，默认 dry-run，仅 --execute 删除。
- 只候选 64 位 hex 匿名 Docker volume，execute 前二次 docker ps -a --filter volume 检查 refs=0。
- 不用 docker volume prune，不处理命名业务卷。当前 dry-run 候选 2 个，总约 96MB，未执行删除。

真实验证：
- bash -n 通过。
- getent hosts api.day.app 已解析到公网 43.155.109.24，curl -I https://api.day.app 返回 HTTP/2 200。
- 手工强制阈值 1 且加载 env 后，Bark direct 发送成功：success mode=curl_api_direct，输出 ALERT host=mason-main threshold=1 count=1 / 71%。
- systemctl start monchk-disk-alert.service 真实跑默认阈值 85 成功，当前 / 71%，输出 OK threshold=85。
- timer active。

请重点审查：
- 这是否足以解释“有报警为什么还出事”？
- 修复是否会误删生产数据或影响 SubLB/Caddy/Postgres/Redis？
- 脚本改动是否还有明显缺陷？
- 是否建议立即补充 heartbeat 或第二通知通道？

请用中文，先给结论，再给风险和建议。