[JunieXD]

关联

路线图 #2「证据只在图片里的值送审核页」，抓取节点上线前要有。Refs #102、#106

改了什么

图片和扫描件的文字是 DeepSeek 读出来的，认错的字在快照里照样原样找得到，看着也像对的，证据校验拦不住，所以这类字段要交给人核对（总体设计 §8.3）。

• 抓取节点：交附件时带上 read_from_pictures，文字里有从图片或扫描页读的部分就为真。存着没重读的也算：存下来的都是读图的结果。
• 网站：attachments 表加同名的列；附件改成从图片读的也算快照变了。证据有一句出自这种附件的字段不上表，以 evidence_in_picture 进审核页，通过的照抽出来的值上表，和置信度低的一样。
• 审核页加上「证据在图片里」。总体设计 §8.3、§5.2、§12 和数据表文档写上这条规则。

怎么验证的

• 网站 pnpm check 通过，101 个测试；新测试：一条通知的字段证据分别在正文、普通附件和图片附件里，只有图片里的两个进审核页。
• 抓取节点 ./check.sh 通过，344 个测试；读图的测试里，第一次读和用存着的结果，附件都标为从图片读的。
• 加了表结构，本地的库要重建（0001_init.sql 直接改，上线前没有历史包袱）。
• 另请 Codex 逐文件审过、在单独的库里跑过检查。它复现了一个问题：附件文字没变、这次改成从扫描页读的，网站沿用旧快照，标记被吞掉，字段直接上表。已改成这种情况也存新快照（总体设计 §7.4），并补了测试。

影响

• 抓取节点接口：POST /notices/{id}/snapshot 的附件多了必填的 read_from_pictures，两边一起改了。
• 表结构：attachments 加一列，review_items.reason 多一种。还没上线，没有已有数据。
• MCP 工具：无。