docs(recall): 宿主跟进闸改推布尔 —— has_active_complex_case,不要条数

上一版定的是 active_complex_case_count(计数),多余:
  - 闸门只判有无,条数 PAC 不消费,纯属未被消费的精度
  - complex_case_info 带 organization_id,跨诊所累加的条数在多品牌 SaaS 里语义含糊;
    EXISTS 反而是干净、且宿主易保证正确的口径
改为 has_active_complex_case(接受 1/0 或 true/false,PAC 归一层 coerce 成布尔)。

PAC 侧字段 hostFollowUpActive 不变(本就是布尔)。

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

@@ -64,15 +64,15 @@ icon: FileJson
 | `organization_id` | string | | 建档诊所 |
 | `contacts_tel` | string | | **默认联系号(宿主 inline)**——按上述规则挑出的有效号码(= customer_contacts 原列名) |
 | `relationship` | string/number | | **该号归属(宿主 inline,= customer_contacts 原列名)**——`PhoneRelationshipEnum`:`1`本人 `2`爸爸 `3`妈妈 `4`爷爷 `5`奶奶 `6`朋友 `7`配偶 `8`子女 `9`其他(PAC 存 `isSelf`=码=='1') |
-| `active_complex_case_count` | number | | **进行中的复杂病例数(宿主 inline,新增)**——宿主侧仍在主动跟进该患者的凭据,PAC 用作召回排除闸。见下方「跟进中患者不进召回池」 |
+| `has_active_complex_case` | boolean | | **是否有进行中的复杂病例(宿主 inline,新增)**——`1`/`true`=宿主正在跟进该患者。PAC 用作召回排除闸,见下方「跟进中患者不进召回池」 |
 | `created_gmt_at` / `updated_gmt_at` | string(datetime) | ✅ | 建档/更新时间 |
 
-#### 跟进中患者不进召回池 —— `active_complex_case_count`(待宿主确认)
+#### 跟进中患者不进召回池 —— `has_active_complex_case`(待宿主确认)
 
 **要解决的问题**:宿主自己正在跟进(已建复杂病例、客服/咨询师在推进)的患者,PAC 不该再发起召回 ——
 否则两边同时联系同一个人,患者体验差,也显得两个系统各说各话。
 
-**取值口径**:该患者名下**未删除**且 `case_stage` 处于以下 4 档的 `complex_case_info` 条数:
+**取值口径**:该患者名下**是否存在未删除**且 `case_stage` 处于以下 4 档的 `complex_case_info`:
 
 | 阶段 | 是否算"进行中" | 理由 |
 |---|---|---|
@@ -83,7 +83,11 @@ icon: FileJson
 | 已成单 | ❌ 不计 | 该需求已转化闭环,患者可被其他理由召回 |
 | 暂停跟进 | ❌ 不计 | 宿主已停止跟进 → 交还给 PAC 召回 |
 
-无进行中病例填 `0`(**不要留空** —— 留空 PAC 按"宿主未提供该信号"处理,不启用该闸)。
+无进行中病例填 `0`/`false`(**不要留空** —— 留空 PAC 按"宿主未提供该信号"处理,不启用该闸)。
+
+**只要布尔,不要条数** —— 闸门只判有无,条数 PAC 不消费。而且 `complex_case_info` 带 `organization_id`,
+跨诊所累加的条数在多品牌 SaaS 里语义含糊,`EXISTS` 反而是干净且宿主易保证正确的口径。
+取值接受 `1`/`0` 或 `true`/`false`,PAC 归一层统一 coerce 成布尔。
 
 **为什么由宿主算、而不是把 `complex_case_info` 整表推给 PAC**
 
@@ -94,13 +98,11 @@ icon: FileJson
    (同 `contacts_tel`、`std_code`、`class_name`)。
 
 > ⚠️ **两处待宿主确认,确认前 PAC 不启用该闸**
-> ① **列名**:`active_complex_case_count` 是 PAC 侧的建议名(取自宿主表名 `complex_case_info`)。
+> ① **列名**:`has_active_complex_case` 是 PAC 侧的建议名(取自宿主表名 `complex_case_info`)。
 >    该列宿主源表尚不存在,属新定义 —— 若宿主内部另有习惯叫法(如模块在日志里也称「潜在治疗」),
 >    以宿主的为准,PAC 改映射即可,**契约纪律是列名随宿主**。
 > ② **`is_del` 语义**:`complex_case_info.is_del` 的注释写「未删除1/已删除0」,与常规惯例相反,
->    而实际数据里 `0` 和 `1` 都有。取数前必须确认哪个值代表"未删除",否则计数会整体反掉。
->
-> 也接受宿主只推布尔(`0`/`1`)而非计数;计数的额外价值是 PAC 将来可据此排优先级,不影响本闸。
+>    而实际数据里 `0` 和 `1` 都有。取数前必须确认哪个值代表"未删除",否则判定会整体反掉。
 
 ### `customer_referee_circle` — 转介绍圈(患者-患者关系)