v0.31.2 — 证据修复批（Flipped 解绑 + 多蒙版底形）

v0.31.2（证据修复批） — 三项，素材=用户自有图库的只读取证（E1-verdict + 多蒙版取证）。

① crs:Flipped 与反相解绑（主项）。全库 201 个径向普查：crs:Flipped 与 crs:MaskInverted 完美反相关（155 + 46，两种相同值组合各 0 例；本批在 7 份 M-B sidecar 上独立复算 23/23，且 27/27 线性渐变根本不带 crs:Flipped）。即 Lightroom 把同一个反相位写了两遍。本引擎的 Radial::flipped 与 inverted 按 XOR 合成，两半都读进来等于把一个值和它的补 XOR——导入的每一个 LR 径向都被无条件反相，与文件内容无关；对 LR 不反相的那 155 个是错的。修＝导入只认 crs:MaskInverted，写出侧两个属性都从净反相派生，因此只会写出 Lightroom 自己会写的组合——这正是该投影在「LR 渲染器到底读哪个属性」两种读法下都成立的原因。实测（E1-verdict §6）：DSC09568 对真实 LR 导出的 tone-matched RMS 0.1099 → 0.0751，蓝通道 0.1901 → 0.0869。我方 flipped 语义不变（仍渲染、仍是 GUI「翻转」勾选），既有 recipe 渲染一像素不变，recipe schema 零改动（不新增字段=不触发 v0.31.0/1 exe 的蒙版硬拒）。已知边界：≤v0.31.1 我方写的带翻转 sidecar 现在读回为不反相——这不是新损失，Lightroom 本来就那样读它，两个方向自此与 Lightroom 一致；往返后净反相精确保留，但承载位从「翻转」并入「反相」勾选。

② 两处注释旋向改正（只改注释，码不动）：render.rs / recipe.rs 都写成「逆时针，y-down 屏幕意义」，实测为顺时针（引擎角 +30 渲出右端朝下；符号检验 5/5，p=0.031，supported 级、未到 proven）。矩阵 R(+θ) 在 y-up 数学系里确是逆时针——旧注释带着 y-up 的读数却声称 y-down。

③ 多蒙版 Correction 取错底形。原选择器按种类选几何（Mask/Gradient 恒优先）且完全无视 crs:MaskBlendMode：DSC08960 蒙版 3 与 _DSC9583 Mask 9 都是「径向底形 + 线性减法」，结果留下 LR 用来抠掉的那块、丢掉底形——是意图反转，不是截断。修＝优先默认 BlendMode 的组件（全为减法时才落到首个）。另修披露失真：Rotation 注记只对实际导入的几何发（DSC08960 原本报四条，三条描述从未进入 recipe 的径向）；BlendMode 保持组件级——它对被丢弃的减法组件是真话，也正是 v0.31.1 为该情形加的披露。实测恢复 3 个蒙版（DSC08960 径向 {3}→{1,3,4}，_DSC9583 {0..7} 全入）。登记不修：CLI 零蒙版披露（通道设计缺口）、unknown_component 预占的参数化形状账（披露粒度设计）。

门：clippy 0（双配置）；610(+4) lib / 8 CLI / 129 GUI / 2+2 合约双配置全绿；audit_i18n 全 9 门 0；无新 zh 词条（字体门不受影响）；6 项变异检查修前必红（主审抽查 first_base.or(first)→first 复现红）。