Explain why CI keeps both submodule SSH endpoint mappings

Why: After the Gitea migration some repositories still declare the legacy
endpoint in .gitmodules while facts F3 names the new one as authoritative. Both
endpoints currently resolve and serve git, so CI needs both insteadOf mappings;
dropping either one makes that batch of pins fall back to real SSH and the
svc-realcombo job fails on host key verification.

Evidence: 2026-10-23 measurement from this machine — both endpoints answer
git ls-remote with the same HEAD; Agent-System-Dev declares 14 submodule URLs on
the legacy endpoint, Agent-System-Backend 10, Agent-System-RDM 8 and
Agent-System-KB-Regulations 2 on the new one.

Impact: comments only; no GIT_CONFIG key, job structure or credential handling
changes.

Refs: feature/ecs-deploy-dev8788-and-kb

.gitea/workflows/ci.yaml

@@ -429,9 +429,13 @@ jobs:
           # https 基址后再取。只追加 pin 的三个 40 位 hex，不 source pin 文件。
           SERVER="$(printf '%s' "$GITHUB_SERVER_URL" | sed 's:/*$::')"
           scheme="${GITHUB_SERVER_URL%%://*}"
-          # 嵌套 pins 的 SSH 端点有两代（旧 git-ssh.* 与迁移后的 gitea.*:52222）；
-          # 只映射旧端点会让嵌套克隆退回真实 SSH，CI 无 key 时必然 host key 失败。
-          # 两个 insteadOf 同键多值，git 会依次匹配。
+          # 嵌套 pins 的 SSH 端点有两代：旧 git-ssh.*:31411 与迁移后的 gitea.*:52222。
+          # 两个 insteadOf 必须同时保留，直到本仓与所有组件仓的 .gitmodules 全部迁到
+          # 新端点（policy/facts.md F3 已把新端点列为权威；2026-10-23 实测本仓
+          # .gitmodules 仍有旧端点子模块，Agent-System-Backend 亦然）：
+          #   · 去掉旧端点映射 → 旧端点声明的子模块退回真实 SSH，CI 无 key 必失败；
+          #   · 去掉新端点映射 → RDM/KB 等已迁移的 pins 同样退回真实 SSH 而失败。
+          # 同键多值，git 会依次匹配。
           export GIT_CONFIG_COUNT=5
           export GIT_CONFIG_KEY_0="protocol.$scheme.allow"
           export GIT_CONFIG_VALUE_0="always"
@@ -723,9 +727,13 @@ jobs:
           # https 基址后再取。
           SERVER="$(printf '%s' "$GITHUB_SERVER_URL" | sed 's:/*$::')"
           scheme="${GITHUB_SERVER_URL%%://*}"
-          # 嵌套 pins 的 SSH 端点有两代（旧 git-ssh.* 与迁移后的 gitea.*:52222）；
-          # 只映射旧端点会让嵌套克隆退回真实 SSH，CI 无 key 时必然 host key 失败。
-          # 两个 insteadOf 同键多值，git 会依次匹配。
+          # 嵌套 pins 的 SSH 端点有两代：旧 git-ssh.*:31411 与迁移后的 gitea.*:52222。
+          # 两个 insteadOf 必须同时保留，直到本仓与所有组件仓的 .gitmodules 全部迁到
+          # 新端点（policy/facts.md F3 已把新端点列为权威；2026-10-23 实测本仓
+          # .gitmodules 仍有旧端点子模块，Agent-System-Backend 亦然）：
+          #   · 去掉旧端点映射 → 旧端点声明的子模块退回真实 SSH，CI 无 key 必失败；
+          #   · 去掉新端点映射 → RDM/KB 等已迁移的 pins 同样退回真实 SSH 而失败。
+          # 同键多值，git 会依次匹配。
           export GIT_CONFIG_COUNT=5
           export GIT_CONFIG_KEY_0="protocol.$scheme.allow"
           export GIT_CONFIG_VALUE_0="always"

tests/test_svc_realcombo.py

@@ -49,9 +49,10 @@ def ci_git_env():
     if not (CI_SERVER and CI_TOKEN):
         return {}
     scheme = CI_SERVER.split("://", 1)[0]
-    # 嵌套 pins 的 SSH 端点有两代：旧 git-ssh.* 与迁移后的 gitea.*:52222。
-    # 只映射旧端点会让 pins 取件退回真实 SSH，而 CI 运行器没有 key，必然
-    # host key verification failed。同键多值，git 会依次匹配。
+    # 嵌套 pins 的 SSH 端点有两代：旧 git-ssh.*:31411 与迁移后的 gitea.*:52222。
+    # 两个 insteadOf 必须同时保留，直到所有 .gitmodules 迁到新端点（policy/facts.md
+    # F3 已把新端点列为权威；本仓 .gitmodules 仍有旧端点子模块）：任去掉一个，
+    # 对应那批 pins 都会退回真实 SSH，而 CI 运行器没有 key，必然 host key 失败。
     return {
         "GIT_CONFIG_COUNT": "5",
         "GIT_CONFIG_KEY_0": "protocol.%s.allow" % scheme,