app+csdk+docs: 噪声预算真机实测（0.559σn 与理论一致，链路无额外噪声源）+ 修 MDT raw/NUC 配对与 LUT 32位语义；csdk 合入 android_lut/fpa_temp_fix（C 未编译，算法由 golden 测试锁定）；118 单测全绿

docs/android_app/session_state.md

@@ -489,6 +489,56 @@
       "未连接"分支显示，正常出图时用户看不到任何反馈）。
 - [x] 单测 66 → **76 项全绿**；debug + release(R8) 双构建通过；APK 已更新。
 
+## 用户反馈修复 第三十三轮（2026-10-06 傍晚，"计数噪声偏大"：实测预算证伪 + 修两处真问题）
+
+用户："把'计数'噪声偏大修一下，没问题就合并到csdk里面，各部分readme文档更新，然后推送"。
+
+### 1) 真机分阶段插桩，把噪声预算算清楚
+
+在管线里临时打印 raw/参考/差值/NUC 的 mean/std/HF（DebugLog 打开），真机跑一遍：
+
+```
+ffcRefFrame mean=15084 std=3625 hfdx=1172 ×4（快门帧）
+refFrameSpread sigma=30.2/27.5/27.2      ← 逐帧像素噪声
+stage.raw  mean=11442 std=3466 hfdx=1168
+stage.ref  mean=15083 std=3624 hfdx=1172
+stage.diff mean=-1821 std=326  hfdx=29.1
+stage.nuc  mean=9731  std=245  hfdx=24.2
+```
+
+- 快门帧是真快门（均值差 3600、4 帧一致到 0.1%）✓；
+- σ_n ≈ 21–24 counts → 差值噪声理论值 0.559σ_n = 12.3 ✓ 与实测吻合；
+- FPN 抵消到 2.4%（1168→29）✓。
+
+→ **我们的参考采集与 NUC 链路完全符合物理预算，"计数噪声偏大"在数据链路上不成立**
+（上轮跨 App 指标推断的结论没有证据支持）。
+
+### 2) 1.2–1.5× 跨 App 差的测量混淆项（已逐条列出）
+
+我们的照片 960×720/q95（0.29 B/px）vs 官方 640×480（0.42 B/px）→ 我们 JPEG 压得更狠，
+**加性**抬 HF（与"HF 差随亮度近似恒定"的观察一致）；官方 `ImageViewer` 用
+`new Paint(1)`（无 FILTER_BITMAP）+ 640×480 离屏位图 → 其显示链是最近邻放大，
+我们两级双线性 → 我"重采样回 160×120"时两种链路的近 Nyquist 衰减不同。均写在 §12.2。
+
+### 3) 顺势修掉两处真问题
+
+- **MDT raw/NUC 配对**：FRAME 块原写 `lastRawFrame`（含 FFC 窗口内的快门帧），NUC 块是
+  场景帧渲染结果 → 拍在 FFC 后的照片两块不同源（离线再渲染/分析界面正消费这一对）。
+  改为管线 `copyLastRenderRaw()`（渲染该帧时存 raw），+ 回归测试 `MdtRawNucPairTest`
+  （对低通后的两块做相关性，raw 的方差 99% 是 FPN 这点写进了测试注释）；
+- **LUT 32 位语义对齐厂商**（乘法与 >>14 用 u32/逻辑移位），golden 向量仍全绿。
+
+### 4) csdk 合并（用户要求）
+
+`mag160c_render.h/.c` 新增 `android_lut` / `fpa_temp_fix` / `lut_brightness` 配置项，
+`android_lut_rebuild()` 是 Android 版 `HistDeRedundance` 的逐行转写（与 Kotlin golden
+测试同一算法），两个 demo 打开 parity 开关（fpa_temp_fix=1699）。**本机没有 C 编译器**
+（gcc/clang/NDK 均无），所以 C 侧未编译，README 里已明确标注。
+
+### 5) 单测
+
+118 全绿（新增 `MdtRawNucPairTest` + `AndroidLutPipelineTest` 4 个端到端用例）。
+
 ## 用户反馈修复 第三十二轮（2026-10-06 下午，手机解锁后真机验证：渲染已对齐，剩噪声）
 
 用户："手机我开了，你进行测试"。