feat(flow): support dynamic countersign add-sign

docs/adr/0001-model-add-sign-as-dynamic-countersign-append.md

@@ -0,0 +1,7 @@
+---
+status: accepted
+---
+
+# 将加签建模为动态追加会签人
+
+工作流中的“加签”采用动态追加会签人的语义：在当前会签节点仍处于运行状态时，为新增审批人创建独立待办，并将其纳入同一节点的会签完成条件。只有仍持有未完成待办的原始审批人可以发起动态加签；加签审批人、已经完成审批的原始审批人、流程发起人和普通管理员均不能发起。加签成功后，发起人的原待办保持待审批，且不需要等待新增审批人；原审批人与新增审批人的待办并行处理，加签操作本身不代表审批同意。同一流程实例的同一会签节点内，审批人按用户唯一，每个用户最多拥有一份待办；该约束由后端保证，前端同时过滤已有审批人。首版只允许并行会签模式使用动态加签；或签、依次审批和单人审批不提供加签能力。动态加签由流程设计者在每个并行会签节点上显式开启，默认关闭；配置直接保存在现有节点数据中，以简单实现优先，不提供发布版本隔离。一次加签可以选择多名审批人，但必须整批通过校验并原子提交；任何目标不合法时不创建任何新增待办，一次提交只形成一条包含全部新增人员的加签记录。同一原始审批人在完成自己的待办前可以多次发起加签，每次分别校验并记录；其待办完成后立即失去加签权限。首版不提供撤销加签或减签：新增待办一旦创建便作为正式会签待办参与完成条件。加签审批人可以转办自己的待办，但不能发起加签；转办目标不能是当前节点已有审批人，转办仅替换该待办的处理人，不改变会签任务总数。发起加签必须填写 2～100 字的原因；系统记录发起人、新增审批人、原因、时间、流程实例、节点、发起待办及变更前后的会签人员，并在审批记录中展示。桌面端与移动端在同一版本提供一致的加签入口和规则，流程设计配置仍由桌面端承担。现有基于任务委托的 `delegateTask` 保留为“委托”，不作为加签实现，以免委托返回原审批人的生命周期与会签人数变化混为一谈。

docs/adr/0002-use-flowable-dynamic-multi-instance-for-add-sign.md

@@ -0,0 +1,7 @@
+---
+status: accepted
+---
+
+# 使用 Flowable 动态多实例实现加签
+
+动态加签使用 Flowable 原生 `RuntimeService.addMultiInstanceExecution` 向运行中的会签活动添加执行实例，并由 Flowable 作为任务生命周期、实例数量和节点完成状态的唯一事实来源。PIGX 业务表只保存审批人映射、查询投影和加签审计，不创建一套独立的附加审批任务，以避免引擎状态与业务状态发生双写分歧。加签与节点完成发生竞争时，以先提交成功的事务为准：加签先成功则节点等待新增实例，节点先完成则加签失败；系统绝不重新打开已经完成的节点。