EasyBot v0.0.41

Fixed

• 管理后台日志环形缓冲不再无过滤采集依赖库内幕（并修复 RUST_LOG 被忽略） —
  LogCollector 图层此前未挂过滤器，会接收并保存 hyper / sqlx / tower_http /
  axum 等所有 target 的 TRACE/DEBUG 事件：环形缓冲（上限 5000 条）被依赖库噪音占满，
  业务与插件日志被挤掉；同时未过滤的图层不对全局最大级别提供任何约束，tracing 全局最大
  级别被抬到 TRACE，所有 trace!/debug! 宏（包括依赖内的）都被真实构造/记录，带来
  不必要的 CPU 与内存开销。现让内存收集器与控制台 fmt 层共用同一过滤器（默认
  easybot=<level>），并读取 RUST_LOG（存在时接管过滤），兼现 docs/16/docs/17 中
  RUST_LOG=<target>=<level> 可按 target 细分日志的承诺——此前该环境变量被完全忽略。

• 修复空载下匿名内存持续增长直至 cgroup OOM（issue #139） — 事务性 outbox 发布器每 250ms 调用
  unpublished_outbound_events()，其 ORDER BY completed_at, id 缺少覆盖索引，SQLite 每次排序都会
  构建一个 TEMP B-tree；承载该临时结构的匿名内存不会被释放，导致空载下匿名内存单调增长
  （实测空载 ~0.3MB/min，容器最终逼近内存上限并被 OOM kill）。GET /api/v1/messages/deliveries
  与 GET /api/v1/sessions/{key}/export 的 ORDER BY created_at DESC, id DESC 同样退化为临时 B-tree。
  新增 schema 迁移 v4：为 outbound_deliveries 建立
  (event_published, completed_at, id)、(actor_id, created_at DESC, id DESC)、
  (platform, chat_id, created_at DESC, id DESC) 三个索引，使上述查询走索引排序、不再创建临时 B-tree。
  升级前（schema < 4）的库会在启动时自动迁移；CREATE INDEX IF NOT EXISTS 可重复执行。

• 修复 Windows Docker Desktop bind mount 上无法打开既有 gateway.db（Operation not permitted） —
  storage::sqlite::create_pool 在 Unix 下对已存在的数据库文件强制执行 chmod 0600，
  成功与否被当作打开数据库的硬性前提。Windows Docker Desktop 的 bind mount（9p/virtiofs）
  会拒绝对迁移进来的既有文件执行 chmod 并返回 EPERM（os error 1），导致 create_pool
  返回错误、bin/src/main.rs 回退到内存库：消息/outbox 表不存在（no such table: messages）、
  持久化的 API key 无法加载致 REST/WebSocket 认证全部 401。现将权限收紧改为纵深防御：
  失败仅记录 warn 并继续，依赖底层文件系统 ACL 打开数据库；新建文件仍以 0600 创建。
  容器自身创建的库（如 auth.db）权限收紧正常，不受影响。

• 内存回退库不再静默降级：执行 schema 迁移 + 显式报告降级状态 —
  当 SQLite 仍无法打开而回退到内存库时，bin/src/main.rs 现在对内存库执行同一套
  版本化迁移，避免消息/outbox 持久化持续报 no such table: messages /
  outbound_deliveries（此前单容器 2 天可刷出 162MB 日志）。回退日志从 warn
  升为单条 error，附可操作指引（提示属主不匹配与 chown 10001:10001）。
  新增 AppState.storage_ephemeral，/api/v1/ready 在内存回退时把
  message_storage 标为 ephemeral、整体 status 为 degraded 并返回 503，
  /api/v1/health 同步报告 degraded，消除"数据未落盘但健康检查仍绿"的运维盲区。

• 根治下载/插件安装偶发"下载产物为空"缺陷（updater::github::download_binary） —
  根因是 tokio::fs::File 的 write_all 只保证字节拷入内部缓冲并派发后台阻塞写任务，
  poll_write 随即返回 Ready——字节未必已写入 OS。download_binary 未 flush 就
  返回 Ok，调用方（自动更新替换、插件安装）用独立 fd/path 读该文件做 sha256 校验时，
  高负载下会读到尚未落盘的空文件（历史表现为下载测试偶发 sha256 of empty，
  e3b0c442…）。已在返回前补 file.flush().await 等待后台写任务完成，并把 0 字节
  响应判为失败（此前无 Content-Length 的 0 字节完整响应会被静默当成成功）。
  test_download_verifies_sha256 中为此设的 8 次重试循环一并移除——回归即真缺陷，
  应修根因而非加重试预算。