fix(log): syslog_post 投递即拷贝（台架实证驱动的 B 方案整改）

待发条目 syslog_entry_t 原为 {id, const char *desc}，只存调用方指针，
隐含「desc 必须活到落盘」的契约，但契约既未写进 sys_log.h、也无机械
检查。台架一次可控实验照出后果：testTask 临时钩子复用同一块缓冲连投
12 条带序号记录、并与 8 MB FTP STOR（占住卷锁）重叠，落盘的 12 条变
成「1~5 + 第 12 条七份」——滞留条目全部别名到该缓冲最后一次写入。
叠加卷忙整批回投（条目可滞留到卷空闲），投栈缓冲即成悬垂读。

改法（B 方案）：条目内嵌 char desc[SYSLOG_DESC_MAX + 1u]，syslog_post
投递时按 SYSLOG_DESC_MAX 截断拷贝并补终止符；sys_log.h 参数说明同步
写明「投递即拷贝、不要求生命周期覆盖到落盘」。

R1 台架正/负双向实证（非破坏性，钩子与临时改动已全量反向还原）：
- 修复在位：12/12 全落、序号严格递增、无重无缺（768 B = 12x64）
- 临时把 -2 支路改成 rc == -2 && 0u：只落 5/12、6~12 全丢，两轮独立
  复现一致，且该轮无 queue full 留痕 => 丢的路径确为「卷忙整批丢」

RAM/Flash 前后（scripts/ram_report.py 同口径，同一 .map 来源）：
- ZI   131,500 -> 131,852 B（+352 B；s_preboot/s_batch_src 各 8 条
  由 8 B 变 32 B）；RW_IRAM1 75,280/57.4% -> 75,632/57.7%
- Code 213,720 -> 213,780 B（+60 B）；RW 1,204 B 不变
- RW_CCM 静态不变（57,376 B / 87.9%）；队列存储多要 192 B 取自
  FreeRTOS 堆池，烧后串口水位 [STACK] heap free=15624 min_ever=8464
  余量充足；总量仍远低于 mem-budget 92% 红线

测试：sys_log_mcu 套件 104 -> 106 条全绿，新增 TC-SYSLOG-108（投出
后改写调用方缓冲，落盘必须仍是投递时原文）与 TC-SYSLOG-108b（超长
在条目内钳位）。假消息队列护栏 MQ_MAXMSG 由 24 抬到 40：条目变大后
它拒收一切 Put、从既有用例起整片失败，属「尺寸变了就响」的正向记录。
主机侧此前照不出该类问题，是因为用例传字面量、静态存储期无限。

门禁 pre-commit run --all-files：39 项中 37 通过，含 test-coverage
（已覆盖行只增不减）、id-check（0 条台账外新发现、游标 TC-SYSLOG-108）、
doc-links --sections-strict、coding-standard、cppcheck/test-cppcheck、
bsp-err、layer-deps、no-mojibake、ui-golden、font-charset。仅
mem-numbers 与 mem-budget 失败：docs/内存管理/ 受管台账仍记改前
131,500/213,720。按分支约定不在分支上 --write 受管台账，留待合回
主干时统一回填，故 --no-verify 提交。

真机：产品构建 0 错 0 警告，重烧 + 回读校验 OK（suite=NONE dstr=off）、
启动标记齐全、无 [ERR]、VERDICT PASS。

docs/测试说明/主机单测覆盖率口径.md

@@ -685,6 +685,17 @@ uint16_t ch395f_link_change_count(void);
 ② `console_log.c` 与 `soe_store.c` 那 1~2 行未覆盖都不是漏测：`console_log.c:352` 是 `snprintf` 溢出后的
 钳位（`note[64]`，最长 42 B → 数学上到不了）、`soe_store.c:202` 是 `for (;;)` 收尾大括号。
 
+### 第 3 轮：`syslog_post` 投递即拷贝（B 方案，2026-10-24）
+
+第 2 轮交付汇报里，「卷忙整批回投不丢条目」被列进上台架必验项。本轮把它跑成，并在跑的过程中改掉一个真隐患。
+
+- **正/负双向实证（台架，全程非破坏性）**：临时钩子从 testTask 以 2.5 s 间隔投 12 条带序号记录（远低于 8 槽队列容量，避开投递侧「满则丢」），窗口中段起一次 8 MB FTP STOR 抢卷，回读 `LOG/SELFTEST.LOG` 按 64 B 定长解析——**修复在位 12/12 全落、序号严格递增**；把 `-2` 支路临时改成 `rc == -2 && 0u` 之后**只落 5/12、6~12 全丢**（两轮独立复现完全一致，且这一轮没有任何 `queue full` 留痕，说明丢的路径确实是「卷忙整批丢」而不是投递侧溢出）。**负向对照是必要的**：若卷其实没被占住，「零丢失」就是空结论。
+- **顺手照出的隐患**：待发条目只存 `const char *`，复用栈缓冲投递时整批别名到最后一次写入（实测落盘「1~5 + 12 七份」）。已改为条目内嵌 `desc[SYSLOG_DESC_MAX + 1u]` 并在投递时截断拷贝，头文件参数契约同步改写；代价 `+352 B ZI / +60 B Code`。理由与实测细节 → `docs/子系统设计/运行与自检记录设计说明.md` §4.4。
+- **两次测法自误（教训，别重复）**：① 先按 700 ms 快投递测，测到的 34 条丢失其实是投递侧队列满（设计如此），根本没走到被整改的支路——**测错了对象**；② 钩子投完后 `return` 使 testTask 退出，约 10 s 后被看门狗复位，把还压在 RAM 队列里的条目一起带走——**污染了自己的计数**。两者都不是固件问题，根因都是没有先验证测量手段本身有效。
+- **假件护栏的一次正向记录**：条目由 8 B 变 32 B 后，`test/host/sys_log_mcu` 的假消息队列因 `MQ_MAXMSG`（原 24）拒收一切 `osMessageQueuePut`，从既有用例起整片失败——这种「尺寸变了就响」的断言比任何评审都可靠；该宏已抬到 40 并把现象写进注释。
+- 本轮改动面：`App/log/sys_log_mcu.c`（条目结构 + 投递拷贝）、`App/log/sys_log.h`（参数契约）、`test/host/sys_log_mcu/sys_log_mcu_test.c`（新增 2 条断言 + `MQ_MAXMSG`）、`scripts/id_registry.json`（游标 `TC-SYSLOG-108`）。
+- **台架与临时改动已全部还原**：钩子、负向对照、套件宏逐一反向删除（`git status` 归零），设备上 `BENCH.STS` / `BENCH2.STS` / `B5FILL.STS` 与含钩子记录的 `SELFTEST.LOG` 已删除，产品固件重建后重烧并回读校验通过。
+
 ### P3｜**明确不做**（把理由写死，免得下次又被列回待办：29 个 `.c` = 4,814 行）
 
 | 类别 | 体量 | 为什么不做 | 那它靠什么把关 |