docs(d2-02-p5): Kafka 5MB上限持久化到108 server.properties + 标注医院现场须同样配

进108核对:server.properties原无message.max.bytes(此前只动态设)。已写入文件
message.max.bytes=5242880+replica.fetch.max.bytes=5242880(备份.bak-20260626,未重启Kafka)。
运行期动态值(KRaft元数据扛重启)+文件值双保险。文档无另外的生产/医院服务器凭证,
108即当前唯一部署服务器;医院现场Kafka须同样放开,已纳入部署清单待办。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

项目文档/进度/D2-02-第三阶段-自动对焦重构-特殊情况记录.md

@@ -147,7 +147,8 @@
 - **堵点2:data-transmission 服务昨日遗留半死**。改完Kafka后图能进topic(三分区共~2017条),但**消费组无图片组、服务不监听10030端口**。查其日志停在昨天14:35、末尾为 Feign/Ribbon 负载均衡调用失败栈——它启动时 addTl 流程(遍历TL→startPictureReceiveTopic 开图片消费)的Feign调用失败,致图片消费者从未启动。**修:照 start-all.sh 命令重启 data-transmission(需 lib 原生DLL JavaImageDLL/opencv_world3416 在PATH + jna.library.path,-Xmx256m)**。
 - **验证(端到端全链路打通)**：重启后 data-transmission 10030监听、日志 `ReceivePictureMessageInfo#receive` 收图入库;消费组 `wyl02` 出现;**服务器 picture_neo_1_20230411_<舱> 今晚入库 house2=203/4=294/6=408/8=205(共1110+),FastDFS 新增4510文件**。链路:本地四步对焦→FocusZ上报→服务器排对称层→取层→拍照→存图(2592×1944)→Kafka→data-transmission→MySQL+FastDFS,**全通**。
 - 影响面：两处修复均为测试环境服务侧配置/运维(Kafka上限、服务重启),无代码改动。控制侧端到端早已验证(对焦闭环+多舱崩溃根治)。
-- 待用户回头确认：① Kafka message.max.bytes 在正式部署环境是否已放大(测试服我设了5MB,正式环境需核对);② data-transmission 昨日 addTl 启动期Feign失败的根因(依赖服务启动顺序/Nacos注册时序)——本次靠重启绕过,正式环境建议查启动编排;③ 图片消费组名 `wyl02` 似为开发期遗留命名,留观察。
+- **2026-06-26 补:Kafka 5MB 上限已持久化到 108**——除运行期动态设置(KRaft元数据,扛重启)外,已写进配置文件 `/opt/kafka/config/kraft/server.properties`(message.max.bytes=5242880 + replica.fetch.max.bytes=5242880,已备份 `.bak-20260626`,未重启Kafka;运行期由动态值覆盖,文件值待下次自然重启从文件生效)。108 即当前唯一部署服务器(文档无另外的生产/医院服务器凭证)。
+- 待用户回头确认：① **真正医院现场的 Kafka 须同样放开 message.max.bytes/replica.fetch.max.bytes≥图片大小(建议5MB),应纳入部署清单**(108 已处理,现场那台我无凭证访问);② data-transmission 昨日 addTl 启动期Feign失败的根因(依赖服务启动顺序/Nacos注册时序)——本次靠重启绕过,正式环境建议查启动编排;③ 图片消费组名 `wyl02` 似为开发期遗留命名,留观察。
 
 #### [Phase5·#6] 三门验证 + 电机安全:真机数据取证结果  — 2026-06-26
 - 在4舱(2/4/6/8)同时对焦+拍照的真机run上,从日志/代码取证四项: