OpenHarmony 5.0跨设备协同中，FormExtensionAbility进程出现“幽灵锁”，杀进程返回ERR_DISTRIBUTED_SCHEDULE_PROCESS_LOCKED，底层触发逻辑是什么？

场景前提

1. 设备集群：搭载OpenHarmony 5.0的智慧屏（主设备）+ 鸿蒙智联工业平板（从设备）+ 轻量级穿戴设备（辅助设备），已完成分布式软总线配对、权限授信，组网采用静态IP+蓝牙双模兜底的分布式组网方案。
2. 应用架构：基于Stage模型开发，主应用通过FA模型实现ServiceExtensionAbility类型元能力卡片，借助DistributedDataObject完成跨设备数据同步，元能力卡片配置为“跨设备可迁移+后台常驻”。
3. 触发条件：智慧屏主应用调用 startAbilityByCall 启动工业平板的FormExtensionAbility，同时穿戴设备通过 DistributedSchedule 发起元能力卡片updateForm 请求时，偶发触发异常。

核心谜题（四层嵌套）

1. 进程锁机制：工业平板的FormExtensionAbility程被标记为“僵尸进程”，但 ProcessManager 显示其状态为RUNNING，资源占用持续增长，调用 ohos\_process\_kill杀进程返回 ERR\_DISTRIBUTED\_SCHEDULE\_PROCESS\_LOCKED ，该锁的底层触发逻辑是什么？
2. 元能力拦截逻辑：穿戴设备 updateForm 请求被 FormManagerService 拦截，日志输出 ERR\_FORM\_MIGRATE\_TARGET\_DEVICE\_NOT\_SUPPORT ，但工业平板 form\_config.json 已配置 supportCrossDeviceMigration=true ，且 device\_profile 标记为FORM\_SUPPORTED，此矛盾的底层模块诱因是什么？
3. 数据回调异常：异常发生时，DistributedDataObjec的 dataChange 回调重复执行3次（仅绑定1次监听且已在 onRelease 解除），该现象是否与分布式数据事务一致性协议相关？
4. 上架合规维度：此类未在官方《上架合规检测指南》明确的跨设备元能力进程异常问题，提交鸿蒙应用市场时需补充哪些自定义兼容性测试报告维度才能通过审核？

   补充线索（可能含有干扰项）

• 日志偶现 hiviewdfx 模块输出 DISTRIBUTED\_SCHEDULE: meta\_ability\_route table hash conflict；
• 工业平板 /system/etc/distributed\_config/schedule\_policy.xml 无自定义修改；
• 已申请 ohos.permission.DISTRIBUTED\_DATASYNC 、 ohos.permission.RUNNING\_IN\_BACKGROUND 等全部相关权限，等级为system\_core。