chore(deps): bump the all-actions group across 1 directory with 3 updates

.github/workflows/_acceptance.yml

@@ -12,7 +12,7 @@ jobs:
       - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
         with:
           persist-credentials: false
-      - uses: jdx/mise-action@fc42bcc7ddbf51124c30f95a877a0c5168a3bfde # v5.2.1
+      - uses: jdx/mise-action@6be3c7ed4c21d4f76b208d351d95aac273ebb76d # v5.2.4
       - uses: actions/setup-java@b843ebf9b913146b38da2eaa7aeddf76074ae1ad # v6.1.0
         with:
           distribution: temurin
@@ -33,7 +33,7 @@ jobs:
         with:
           persist-credentials: false
       - uses: ./.github/actions/setup-frontend
-      - uses: jdx/mise-action@fc42bcc7ddbf51124c30f95a877a0c5168a3bfde # v5.2.1
+      - uses: jdx/mise-action@6be3c7ed4c21d4f76b208d351d95aac273ebb76d # v5.2.4
       - uses: actions/setup-java@b843ebf9b913146b38da2eaa7aeddf76074ae1ad # v6.1.0
         with:
           distribution: temurin

.github/workflows/_agent.yml

@@ -17,7 +17,7 @@ jobs:
         with:
           persist-credentials: false
       - name: Setup Python 3.11
-        uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0
+        uses: actions/setup-python@6d4fd22b20465ccc0f7354476588e8df7c9ca0e0 # v7.1.0
         with:
           python-version: '3.11'
       - name: Install locked uv version

.github/workflows/_backend.yml

@@ -244,7 +244,7 @@ jobs:
           persist-credentials: false
 
       - name: Setup mise for repository toolchain
-        uses: jdx/mise-action@fc42bcc7ddbf51124c30f95a877a0c5168a3bfde # v5.2.1
+        uses: jdx/mise-action@6be3c7ed4c21d4f76b208d351d95aac273ebb76d # v5.2.4
 
       - name: Setup JDK 17 for registry contracts
         uses: actions/setup-java@b843ebf9b913146b38da2eaa7aeddf76074ae1ad # v6.1.0

.github/workflows/ci.yml

@@ -56,7 +56,7 @@ jobs:
         with:
           persist-credentials: false
       - name: Setup Python
-        uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0
+        uses: actions/setup-python@6d4fd22b20465ccc0f7354476588e8df7c9ca0e0 # v7.1.0
         with:
           python-version: '3.11'
       - name: Install pinned policy dependency

.github/workflows/docker-publish.yml

@@ -65,7 +65,7 @@ jobs:
           fi
           echo "version=$VERSION" >> "$GITHUB_OUTPUT"
       - name: Log in to GHCR
-        uses: docker/login-action@dbcb813823bdd20940b903addbd779551569679f # v4
+        uses: docker/login-action@81c6f93d4bc991e510b342a00b419b3bb4efc5c6 # v4
         with:
           registry: ${{ env.REGISTRY }}
           username: ${{ github.actor }}
@@ -211,7 +211,7 @@ jobs:
         with:
           cosign-release: v2.5.3
       - name: Log in to GHCR
-        uses: docker/login-action@dbcb813823bdd20940b903addbd779551569679f # v4
+        uses: docker/login-action@81c6f93d4bc991e510b342a00b419b3bb4efc5c6 # v4
         with:
           registry: ${{ env.REGISTRY }}
           username: ${{ github.actor }}

docs/DEVELOPMENT.md

@@ -166,6 +166,27 @@ HTTP 存活不代表 Dubbo 接口已被消费者发现。Admin readiness 额外
 有界发现期限内检查 ProblemFactsPort 与 SubmissionUserReadPort，成功后才输出 launcher
 使用的就绪标记；超时则启动失败。检查只读取发现状态，不调用业务 RPC 或重试写入。
 launcher 记录本次启动前日志偏移，旧标记不会被当成本次成功。
+Submission 门禁另外按固定接口别名记录最终诊断，仅含固定状态/类型枚举、有界耗时和目录计数。
+诊断不调用 `isAvailable()` 或业务 RPC：Dubbo availability 检查可能触发失效/重连，
+只保留原门禁的 availability 判据，诊断仅读取已知目录的元数据。目录计数范围为 0–10000，
+缺失、超限和读取异常分别标为 UNKNOWN、OVERFLOW、ERROR；未知实现标为 UNSUPPORTED，
+不读取其目录字段。计数不是原子快照，正数不等于 ready，也不能据其数量推导等式。
+诊断独立于成功判定，不改变发现期限或重试策略。安装报告保留日志尾部最多 16 条
+此类观测，以及 launcher 最后一次 readiness/PM2 快照，不上传原始日志或环境。
+这些历史观测没有按进程代次关联，也不能证明 App 与 Submission 启动的因果顺序；
+自动重启后 ready 不能作为首次启动失败已修复的证据。
+真实安装验收在 launcher 返回后要求本次隔离 PM2 home 内的 Submission 已 ready、online、
+restart count 为 0；缺失、无效或其他运行的快照也会失败，不能靠自动重启通过。
+App readiness 另外读取 `SubmissionUserQueryPort` 与 `AccountQueryService` 的相同目录元数据，
+仅在两种固定接口别名的观测变化时记录，不调用 availability、业务 RPC 或读取 URL，也不改变
+原有 HTTP readiness 判定。安装报告独立保留 App 日志尾部最多 16 条此类观测；它们不是跨进程
+调用链，不能把历史 Auth 查询异常自动归因为另一次 Submission 请求的失败。
+App 还单独读取现有 application child 的目录，以及已有 listener 的应用数、已收到实例事件的应用数和实例总数，
+同样只输出固定枚举和有界数量，不读取或输出应用名称、实例内容、URL，不创建或刷新发现订阅。
+选中目录与 application child 分开记录，不能把空 DYNAMIC 目录直接认定为应用级实例缺失。
+验收退出时只在已经进入启动阶段后读取一次 Admin 原有 readiness HTTP 响应，报告仅保留固定组件的 UP/DOWN/UNKNOWN，
+此观察晚于 launcher 快照，不改变原退出码、就绪条件或超时。
+
 
 测试账号仅由 disposable dev bootstrap 与 Auth registration 创建。Manager 的直接权限
 通过真实 Auth API 临时授予并过期，不改全局 role policy；Console participant 保持 USER。
@@ -189,6 +210,18 @@ ACCEPTANCE_DISPOSABLE=true bash scripts/ci/business-acceptance.sh
 
 `dev-lite` 是兼容默认：按 `auth → admin → app → notification → submission` 应用 Owner migrations，启动六个后端（含 Judge）并使用数据库 Search；不启动 Search worker，默认也不启动两个前端。`dev-lite` 与 `dev-full` 都要求 `APP_SUBMISSION_ROUTING_MODE=remote` 和 `SUBMISSION_CUTOVER_COMPLETE=true`；marker 未完成时 `up.sh` 会 fail closed。
 
+当所选 PM2 集合同时包含 App 与 Submission/Judge 时，`up.sh` 先启动其余所选进程并等待 App 的 `/api/v1/app/health/ready`，再启动 Submission/Judge；不含 App 的部分选择不额外启动或等待 App。App 超时且选择了 Submission 时，launcher 非零退出，不启动延后的 Submission/Judge，也不保存本次 PM2 集合；已经运行的进程不会因此被停止。仅延后 Judge 的选择保留原有自动重连回退。此顺序与生产 Compose 的 Submission → App healthy 依赖对齐，但 App HTTP readiness 不证明 Dubbo provider 已注册，Submission discovery gate 及其超时保持不变。Submission/Judge 的就绪日志偏移在各自启动前记录，忽略旧 banner 及等待 App 期间旧进程产生的 banner。
+
+本次 launcher 已为管理员 bootstrap 启动的 Auth 会被复用，不在最终批次中再次重启。所选集合同时包含 Auth 与 App 时，先启动或复用 Auth，并重新确认 `/api/v1/auth/health/ready`，再启动 App；Auth 超时则非零退出，不启动 App 及其延后消费者。未选择 Auth 时不补起或等待 Auth，Auth-only 的 bootstrap 路径不发出空的 PM2 启动批次。HTTP readiness 不是 Dubbo 服务发现证明，最终仍须通过真实业务验收。
+
+App、Judge 的 Submission 引用以及 Admin 的 App/Submission 引用通过 Dubbo `providedBy` 显式声明已知 Owner 应用，
+避免消费者先启动时仅依赖首次接口到应用的映射通知。地址仍由 Nacos 实例发现提供；group、version、
+查询/写入重试与超时、身份校验、`APPLICATION_FIRST` 和所有 readiness 门禁保持不变。
+默认目标分别是 `backend-app` 与 `backend-submission`。独立部署若覆盖了 provider 的 `DUBBO_APPLICATION_NAME`，
+需在相应消费者设置 `ulticode.rpc.providers.app` 或 `ulticode.rpc.providers.submission`；对应环境变量为
+`ULTICODE_RPC_PROVIDERS_APP`、`ULTICODE_RPC_PROVIDERS_SUBMISSION`，值必须匹配实际 provider 应用名，
+不能使用消费者自己的 `DUBBO_APPLICATION_NAME`。标准 PM2/Compose 应用名无需额外设置。Judge 的执行栅栏与判题结果回写均使用同一 Submission 应用声明，写入仍为零自动重试。
+
 按开发场景选择最小服务集合（`up.sh`/`stop.sh`/`doctor.sh` 共用同一 resolver，见 `scripts/dev/devstack-manifest.sh`）：
 
 ```bash
@@ -347,6 +380,8 @@ Management forms use patched Zod 4 through `src/lib/toTypedSchema.ts`, which pre
 vee-validate 4 form contract for parsed values, defaults, field errors and required metadata.
 The published Zod 3 adapter is not used; production dependency audits retain the high-severity gate.
 
+Nacos 客户端使用官方 `pure` classifier，并显式引入同版本 `nacos-api`、`nacos-common`，由共享 RPC 模块提供给各 Owner/Worker；排除 Dubbo 引入的默认 shaded client，避免其内嵌依赖绕过 Maven 的安全版本管理。依赖升级须保留 protobuf 消息解析与 loopback gRPC 回归，并由镜像扫描及真实安装 CI 验证。Guava 升级不修复 Nacos 旧 protobuf 生成代码的资源放大风险；本地消息回归也不证明该风险已消除或线上可利用。
+
 后续变更必须保留以下基线契约：
 
 - Console 与 Management 保持各自路由、布局和权限边界，跨端行为归属现有 focused package；