docs(friday): 补 std_check_class 独立小节 + 字典改增量推 + 作用域澄清

- std_check_class 此前仅在 med_check 末尾一行带过 → 补成与 std_diag 对齐的正式字段小节;
  §4 病历链 3→4 个 source(14 张源表全部有独立小节)
- 两字典作用域澄清:按品牌维护、但 code(diag_code/class_code)全局唯一 → lookup 不需租户限定
- 推送方式从「变更时全量重推」改为「按 code upsert、增量推变更行」(与其他表一致);
  规模更正:std_diag 生产多品牌合计 1.5万~3万+行(非测试库 4 品牌的 2739),全推确实浪费。
  依赖 PAC 侧持久化字典存储(落地中)

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

apps/pac-docs/content/docs/integration/friday-push-payload.mdx

@@ -98,7 +98,7 @@ icon: FileJson
 
 ---
 
-## 4. 病历链(3 个 source)
+## 4. 病历链(4 个 source)
 
 ### `med_emr_info` — 病历正文(Mongo 平铺;一张表喂诊断/治疗/建议/复查/病历全链)
 
@@ -130,14 +130,18 @@ icon: FileJson
 
 > 牙位格式:FDI 牙位号,多牙分号分隔,可带牙面字母(`"42 L;43 D"` / `"11;12;13"`)。
 
-### `std_diag` — 诊断字典(低频;变更时全量重推)
+### `std_diag` — 诊断字典(诊断链 lookup 用)
+
+`diag[].linkCode` → `std_code` 的翻译字典;**按品牌维护**(各品牌一套诊断词表),但 `diag_code` **全局唯一**(UUID,跨品牌不撞),故 PAC lookup 不需租户限定。
 
 | 字段 | 类型 | 必填 | 说明 |
 |---|---|---|---|
-| `diag_code` | string | ✅ | 字典主键(= `diag[].linkCode` 指向) |
+| `diag_code` | string | ✅ | 字典主键(= `diag[].linkCode` 指向;全局唯一) |
 | `diag_name` | string | ✅ | 诊断名 |
 | `std_code` | string | | 标准码(`K02.901` 等;K 开头 PAC 截 K 大类,非 K 按自由文本处理) |
 
+> **推送方式**:字典是 lookup-only 参考数据,**按 `diag_code` upsert、增量推变更行**(与其他表一致,`updated_gmt_at` 驱动;PAC 侧持久化字典存储落地中)。
+
 ### `med_check` — 影像档案(metadata,不含文件本体)
 
 | 字段 | 类型 | 必填 | 说明 |
@@ -155,7 +159,17 @@ icon: FileJson
 | `shooting_time` | string(datetime) | ✅ | 拍摄时间 |
 | `created_gmt_at` / `updated_gmt_at` | string(datetime) | ✅ | |
 
-配套字典 **`std_check_class`**(低频):`class_code`(主键) / `class_name`(口内像照片、小牙片、全景片…) / `tenant_id`。
+### `std_check_class` — 影像类型字典(med_check 配套 lookup)
+
+`med_check.class_code` → 影像类型名的翻译字典,PAC 再映射成 modality。**按品牌维护**,`class_code` **全局唯一**(UUID),lookup 不需租户限定;类型少(全品牌合计约几十种)。
+
+| 字段 | 类型 | 必填 | 说明 |
+|---|---|---|---|
+| `class_code` | string | ✅ | 字典主键(= `med_check.class_code` 指向;全局唯一) |
+| `class_name` | string | ✅ | 影像类型名(口内像照片 / 小牙片 / 全景片 / CT影像截图 / 口腔扫描…) |
+| `tenant_id` | string | | 品牌 GUID(字典按品牌维护) |
+
+> **推送方式**:同 `std_diag` —— lookup-only 参考数据,按 `class_code` upsert、增量推变更行(PAC 侧持久化字典存储落地中)。
 
 ---
 
@@ -289,5 +303,5 @@ icon: FileJson
 |---|---|
 | `organization_name` 覆盖 | 目前仅病历/影像表带诊所名,**只覆盖有病历记录的诊所**;其余诊所前端回退显示 GUID。若贵方有组织树接口(如 `regional_nodes_structure`),提供 `诊所 id → 名称` 全量表可补齐 |
 | 品牌名 | PAC 当前**不需要**品牌中文名(无展示位,内部按品牌 id 标识)。将来若有展示需求,再约定推品牌主档(`tenant_apply.tenant_info` 的 `tenant_id`/`name`)——贵方 `tenant_name` 未冗余进业务表,只能走主档 |
-| 字典表推送频率 | `std_diag` / `std_check_class` 变更不频繁,按"变更时全量重推"即可,无需增量 |
+| 字典表推送 | `std_diag`(生产多品牌合计可达 1.5万~3万+行)/ `std_check_class`(几十种):**按 code upsert、增量推变更行**(与其他表一致,`updated_gmt_at` 驱动);不必全量重推。依赖 PAC 侧持久化字典存储(落地中) |
 | 测试环境数据特征 | 部分租户为开发沙盒(诊所名如"XX专用诊所勿动"),字典类映射(治疗类别关键词等)待**生产数据**回流后再校准一轮 |