[Pau1am]

改了什么

基于 main 662a771（v1.6.2）删除 8 处针对不可能发生状态的防御：

位置	原写法	为什么是噪音
serverinfo.py	most = max(votes.values()) 后 if most <= 0: return None	上一行已 if not votes: return None，计数只由 +1 增加
scanner.py	_loads_lenient 里 len(raw) > METADATA_SIZE_LIMIT	上游 _read_entry_capped 超限即抛，同一道边界查两遍
downloads.py	resolve_folder 的「Defence in depth」再 resolve() 比较父目录	注释自己承认逃逸已不可能；每次还多两次 resolve() 系统调用
downloads.py	outcome = None + outcome is not None + # type: ignore	循环至少一次且每轮赋值
installer.py	取 record["file"] 后再判空 + 再 is_safe_component	同一 record 十行前刚在 _install_one_locked 校验过
__init__.py	try: getattr(target, name) except AttributeError: continue	_NUMERIC_RANGES 是静态表且测试反过来断言每条路径都存在
__init__.py	if server is not None: server.logger.debug(...)	同函数末尾无条件用 server.logger，此处必不为 None
__init__.py	try: DownloadLedger(...) except Exception: return 0	构造函数走 read_json（已吞 OSError/ValueError），无失败路径

为什么

按既定口径：不为「保证 0 报错」写过多防御性代码，只保留真实可达失败状态的防护。

保留的防护

Modrinth HTTP 重试与限流、缓存/台账损坏恢复、版本比较边界、单个坏 jar 隔离、删除前 TOCTOU 复查、并发锁与 finally 复位——未动。

验证

• pytest -m "not e2e"：883 passed, 2 deselected（改前基线同样全绿）
• ruff check .（与 CI 同版本 0.17.0）：All checks passed
• tools/check_python_floor.py：53 个文件通过 3.8 检查
• 变异检查：tools/mutation_check.py 的 12 个锚点逐条套用到当前源码，12/12 仍唯一命中
• e2e 未跑：需真 MCDR 启动约 2 分 20 秒，被 marker 排除，CI 有独立 job