release 1.4.0

Highlights

• 扫描管线存活性 — 必需的消费组集中在 airlock.REQUIRED_GROUPS 一处声明。消费组被删除后，
  整个拓扑 1 秒内自愈；此前 monolith 的 workers 组不会自动恢复，实测零吞吐持续了 26 分钟，
  而健康面板始终显示 ok。新增事件循环停摆探测器；解包改在线程里执行，突发负载下
  /healthz 的最大延迟从 30016ms 降到 41ms。
• 进度、准入与沉默引擎 — GET /v1/scans/{id} 现在总会带 progress 对象，能区分"卡住"和
  "忙"。管线超过阈值时，两条提交路径都返回 429 和 Retry-After。持续不交付结果的顾问型引擎
  会被移出等待集，并在判定里写明 advisory_engine_silent:<engines>；按扫描是否真的等过它来判定，
  并设有时效上限，引擎恢复后会自动回到等待集。
• 13 个自研引擎与评分方案 p4 — 检测引擎加固，评分新增 SC1–SC6 守卫和降级分类。
  在 186 个包上与旧版逐包零差异；在 60 个混合语料上，判定只收紧、没有放宽。
• 动态沙箱执行器（gVisor + Kubernetes） — 在隔离的 Job 里真正执行技能包，v1 只放行 DNS 陷阱，
  其余网络一律拒绝。执行在 monolith 内的异步通道中进行，不再拖住 worker tick。通道按积压
  弹性决定宽度，沙箱 ResourceQuota 由 maxConcurrency 推导。因容量不足而证据不全的扫描，
  会在通道空闲时自动补全重扫，最多 2 次。默认关闭，节点上必须先装好 gVisor RuntimeClass。
• 吞吐 — 同一批 60 个真实包、判定逐包不变的前提下：181s（4 核）→ 140s → 88s（8 核）。
  其中一处是存在已久的缺陷：engine-runner 的内联引擎在事件循环上阻塞执行，配置的"宽度"
  从未让它们真正并行。
• 结果收集与重投 — 收集器每个 tick 按时间预算排空结果流；sweep 在 workers 组或结果流有积压时
  不再重投扫描。执行器开启时，重投从 156 次降到 0，用时从 848s 降到 230s。

升级须知

• 缓存身份变化：评分方案升到 p4，执行器配置也计入缓存身份，所以升级后同样内容的包会重新判定，
  不会沿用旧结果。
• 客户端可见的变化：管线过载时提交接口返回 429 并带 Retry-After，调用方需要按它退避重试。
• 新增配置项：
  • engineRunner.maxConcurrency：默认 3，engine-runner 沙箱层的宽度上限。加核后要连同
    limits.cpu 一起调高，否则加的核用不上。
  • dynamicSandbox.executor.laneDrainTargetS：默认 30，决定积压清空过程中通道保持多宽。
    它不会抬高峰值，峰值仍由 maxConcurrency 和 quota 限定。
  • SKILLSCAN_ENGINE_SILENCE_WINDOW：默认 20，判定引擎沉默的样本窗口。
  • 沉默排除的时效 max_age_s：默认 900s。
• 改配置的方式：用 helm get values 取出线上真值，合并新键后再 helm upgrade。
  不要只带新键升级，否则其余值会回落到默认值。

所有结论都来自在真实 k3s、MySQL 和 Redis 上的测试：全量 4393 passed，2 个已知的 vendor pin 用例
需要 .git 才能跑。