test(fw-stamp): 身份戳覆盖测试宏——头依赖 + suite/dstr 变体串

问题：__DATE__/__TIME__ 只在所属 TU 被重编时才刷新，而 app_main.c 不依赖
test/board/test_config.h → 只切套件宏的增量构建不重编它，测试镜像与产品
镜像顶着同一个 fw build: 戳，@test 的戳校验对"两种构建互换"完全失明
（2026-10-11 N-31 复测实测：两者戳同为 Oct 11 2026 14:44:11，只有
-CmpFile 回读才发现镜像不同）。

修复（App/app/app_main.c，两条防线）：
- #include "test_config.h" 建立头依赖 → 改 TEST_SUITE_* /
  ENABLE_DESTRUCTIVE_TESTS 必重编本 TU，戳必刷新（根因修复）
- 戳串追加 FW_BUILD_VARIANT = " suite=<TEST_SUITE_NAME> dstr=<on|off>"
  → 戳内容本身区分构建，时间撞车也能分辨

实测：产品 20:36:11 suite=NONE dstr=off ↔ 测试 20:36:40 suite=CH395F
dstr=on ↔ 还原宏后 20:36:55 suite=NONE dstr=off（时间戳每次都变 = 头依赖
真的生效）。@test 全闭环 PASS：戳匹配 + 回读 No difference found +
锚点 x1 + 零 [ERR]。run_boot_test.py 无需改动（戳按"标记后连续可打印
ASCII"抠取，天然吃下新后缀）。

代价：Code 196764 → 196788（+24 B），@build 0 错 0 警。

文档：自动化测试流程.md 补「戳覆盖构建配置」小节与变更记录行；失败模式
表新增一行——戳命中但 suite= 与要跑的套件不符 = 烧的是产品镜像。

门禁：mem-numbers 钩子拦下「RAM 文档快照与 .map 不一致」→ 用
check_mem_numbers.py --write 刷新生成区（ER_IROM1 213,256 → 213,396 B）。

App/app/app_main.c

@@ -27,6 +27,9 @@
 #include "phasor.h"      /* L2 相量层：phasor_init()（系数表 + 实例 + 双区交换） */
 #include "sys_log.h"
 #include "task_watchdog.h"  /* task_wd_seg_report()：round 8 复位不丢"进段打点"上报 */
+#include "test_config.h"    /* 套件开关：身份戳的构建变体串（FW_BUILD_VARIANT）依赖本头，
+                             * 改 TEST_SUITE_* / ENABLE_DESTRUCTIVE_TESTS 必重编本 TU →
+                             * __DATE__/__TIME__ 随之刷新，见 app_main_init() 的戳注释 */
 
 #define DBG_TAG "[APP]"
 #include "dbg_log.h"
@@ -37,6 +40,26 @@
  * 放这里而非 main.c，是因为需要与其它应用级全局量同层、且日志侧更好引用。 */
 volatile uint32_t g_rcc_csr_latched;
 
+/*
+ * 构建变体串（2026-10-11）：把"测试套件开关"编进固件身份戳，见 app_main_init() 的戳注释。
+ * TEST_SUITE_NAME 由 test/board/test_config.h 定义（产品构建 = "NONE"）；
+ * 模拟器等未纳入该头的编译单元退化为空串，不影响戳的可搜索性。
+ */
+#if defined(TEST_SUITE_NAME)
+#define FW_BUILD_SUITE " suite=" TEST_SUITE_NAME
+#else
+#define FW_BUILD_SUITE ""
+#endif
+
+#if defined(ENABLE_DESTRUCTIVE_TESTS)
+#define FW_BUILD_DSTR " dstr=on"
+#else
+#define FW_BUILD_DSTR " dstr=off"
+#endif
+
+/* 身份戳后缀：一段连续 ASCII，保证 .hex 里可原样搜到（run_boot_test.py 抠戳用） */
+#define FW_BUILD_VARIANT FW_BUILD_SUITE FW_BUILD_DSTR
+
 /*
  * 函数功能：把 RCC_CSR 锁存值翻译为可读的复位原因串（见手册 RM0090 §6.3.22）
  * 入口参数：csr - 锁存的 RCC_CSR 值
@@ -114,8 +137,15 @@ int app_main_init(void) {
      * 用途：@test 把"芯片里正在跑的镜像"和"刚编出来的镜像"对上号。此前开机标记
      * 全是固定串（App init OK / Network Init / ...），旧镜像也照样全中，于是
      * "反复重下载、芯片一直是旧镜像"这类事故在自动闭环里完全不可见
-     * （AGENTS.md 烧录铁律记的正是它）。代价：1 条 DBG ≈ 90 B Flash + 30 B 常量。 */
-    DBG_INFO("fw build: " __DATE__ " " __TIME__);
+     * （AGENTS.md 烧录铁律记的正是它）。代价：1 条 DBG ≈ 90 B Flash + 30 B 常量。
+     * ⚠ 戳只在**本 TU 被重编**时才刷新（增量构建），故本文件必须 #include
+     * "test_config.h"：否则只切套件宏（TEST_SUITE_* / ENABLE_DESTRUCTIVE_TESTS）
+     * 不重编本 TU，产品镜像与测试镜像顶着同一个戳，戳校验对"两种构建互换"失明
+     * （2026-10-11 实测：切宏后的测试构建与产品构建的戳一模一样，只有回读校验
+     * 才发现镜像不同）。两条防线：① 头依赖 → 改宏必重编、戳必刷新；
+     * ② FW_BUILD_VARIANT 把套件名与破坏性开关编进戳内容 → 即便戳时间相同，
+     * 产品串与测试串也不同。代价：约 20 B 常量。 */
+    DBG_INFO("fw build: " __DATE__ " " __TIME__ FW_BUILD_VARIANT);
 
     /* 0) 复位原因上报（锁存值由 Src/main.c 在 HAL_Init() 后立即采得）。
      *    放在日志引擎之后、业务初始化之前：任何一次非上电复位都值得在