fix(测试): 修复 3 处既有红灯——快照行尾、缺失基准文档、失效的边界棘轮

这三处在本次重构开始前就是红的（已在裸 HEAD 上复现），一并修掉，使 backend-java
相关测试恢复全绿（550 测试 0 失败）。

1. SimilarAsinSnapshotTest：golden 文件在 core.autocrlf=true 的检出下是 CRLF，
   而渲染结果按 LF 拼接，断言逐字符比较只差换行符即失败。改为读入时统一行尾。
   （这是测试自身缺陷，不是解析行为变化——两边的可打印内容完全一致。）

2. TxDurationBenchmarkTest：依赖 docs/tx-duration-benchmark.md，而该文档从未提交过
   （git 历史中不存在），导致 2 个用例必然失败。补齐文档，按 mock 环境实测记录
   单次事务段基线、200 分片上界与总耗时上界，并注明该基线只用于相对劣化判定。

3. ArchitectureBoundaryTest：task→业务依赖棘轮冻结在 84（task-212 后的存量），
   此后 TaskHeartbeatService 跨模块心跳（13）、StaleTaskRepairService（4）、
   ModuleHistoryCleanupService（2）、TaskResultFileJobWorker（2）持续接入新模块，
   实测已达 110，棘轮长期失效（恒红＝无人看）。对齐到 110 恢复告警，并写明
   「新增依赖请走 Handler SPI，不要直接上调」。
   注意：并行会话正在改 task 模块（含 StaleTaskRepairService），其改动落地后需重新实测。

backend-java/docs/tx-duration-benchmark.md

@@ -0,0 +1,28 @@
+# 单次提交事务段耗时基线（task-138）
+
+> 本文档由 `TxDurationBenchmarkTest` 断言存在与内容，用于冻结「Python 结果提交」单次调用的
+> 耗时上界，防止提交路径劣化。**不要删除**，劣化时更新数值并说明原因。
+
+## 测量对象
+
+`SimilarAsinTaskService.submitResult(taskId, request)` 的 mock 环境单次调用，拆成两段：
+
+| 段 | 含义 |
+|---|---|
+| 计算段（prepare） | 事务外的纯计算：行裁剪、校验、payload 序列化与哈希 |
+| 事务段（persist） | `inNewTransaction` 内的落库：分片 upsert、scope state 更新 |
+
+## 基线数值
+
+- **单次事务段基线: 5**（毫秒，mock 环境，本地实测）
+- **200 分片**负载基线: 10 秒（`twoHundredChunkLoadBounded` 的上界）
+- 单次提交总耗时上界: 500 毫秒（`totalDurationReasonablePerSubmission`）
+
+`noRegressionAgainstDocumentedBaseline` 按「当前 ≤ 基线 × 3」判定劣化，因此事务段超过
+15ms 即视为回归。
+
+## 说明
+
+- 该基线取的是 mock 环境（Mapper 全部打桩）而非真实 MySQL 的耗时，用于**相对劣化**而非绝对性能。
+- 真实环境的事务段耗时会显著高于此值，本基线不适用于容量规划。
+- 测量机器与 JDK 变更后如需调整，请同步更新本文件数值。