feat(sec-core): add offline rpm build

[yangdao479]

Why

V2 RPM 需要在无法从 Cargo 或 npm registry 下载依赖的环境中可复现构建，并验证安装后的制品可用。

What changed

Source0 仅携带源码和锁文件，Source1 携带 V2 Cargo vendor、linux-sandbox vendor 及 OpenClaw npm cache。V2 CI 合并为一个端到端 job：打包 Source0/Source1、基于这两个打包输入构建 RPM、安装 RPM 后执行 E2E。

Related issue

no-issue: 离线构建基础设施改造。

Risk and compatibility

V1 RPM 流程保持不变，_rpm-build.yaml 未改动。PR 默认不上传 V2 artifact；仅 workflow_dispatch 上传最终 RPM。tag release 继续复用同一套 Source0/Source1 打包 action，并校验 tag 版本与 V2 workspace 版本一致。

Validation

• YAML 解析与 git diff --check
• make -n build-all-v2-offline：cargo 与 npm 均使用离线模式
• Alinux4 本地容器：从 Source0/Source1 完成 dnf builddep、rpmbuild -ba，生成 RPM
• PR CI 全绿：V2 端到端 RPM job、V1 RPM、agent-sec-core 测试、Source Build 及 PR 检查均通过

Documentation and rollback

未新增用户文档。回退该提交即可恢复原 V2 CI 路径。

[kongche-jbw]

Review baseline: 4a783df2b3c15b29240fba8d6e9c070bee26c0be...ac405b670ed25717e4ae2d397d50b23f8d98e410

[P2] 将 npm cache 计入 vendor 体积告警

.github/actions/package-vendor/action.yaml:153 的 TOTAL_VENDOR_SIZE 只累加两个
Cargo vendor 目录。新增的 .npm-cache 虽已进入 Source1 和展示的总大小，却未进入
100 MB 判断。因此当 Cargo 部分低于阈值、npm cache 将归档推过阈值时，发布流程会
漏掉既有的大包告警。Possible direction: 在 npm 缓存生成后按整个
VENDOR_STAGING 重新计算字节数，并补一个由 npm cache 单独越过阈值的回归测试。

[kongche-jbw]

补充一下上面自动审查意见之后的完整 review。本轮仍基于 ac405b670ed25717e4ae2d397d50b23f8d98e410，检查了全部 6 个变更文件，也沿着 release、preview、nightly 和通用 RPM 构建入口看了一遍。

把 Source0 和 Source1 分开，并让 CI 从这两个包构建、安装 RPM 再跑 E2E，这个方向我认可。其他组件仍走原有分支，artifact 上传默认行为也保留了，目前没有发现它们的 release 流程被这次改动直接影响。不过有两处建议在合并前再补一下。

1. [P1] ARM64 的离线依赖还没有覆盖到。 package-vendor/action.yaml 第 142 行在 x64 runner 上执行 npm ci，只会缓存当前平台适用的依赖，包括 @esbuild/linux-x64。实际 RPM 构建会执行 npm 安装脚本，ARM64 上的 esbuild 找不到 @esbuild/linux-arm64 后会尝试联网补下载。如果内部 Koji 需要构建 aarch64，这里就会卡住。用 PR 锁定的 esbuild 0.27.7 做最小复现时，先生成 x64 缓存，再在本机 ARM64 离线安装，得到 ENOTCACHED；阻断后续 HTTPS 下载后，安装退出失败。建议补齐目标架构的缓存，或者确认哪些安装脚本可以不执行，并补一次 ARM64 离线验证。现有缓存自检使用 --ignore-scripts，也只在 x64 上运行，还覆盖不到这一条路径。

2. [P2] 原有 V2 RPM 构建脚本需要一起适配 Source1。 新版 spec 第 21 行新增了必需的 vendor 包，%prep 也会解开它；但 scripts/rpm-build.sh agent-sec-core-v2仍只生成 Source0。在隔离目录运行原脚本、用输入检查器替代 rpmbuild 后，确认交给构建器的 Source1 不存在，干净环境下会因此失败。新 CI 已经改走独立的打包入口，所以这次 CI 通过也没有验证到原脚本。建议让这个入口一起准备好 Source0 和 Source1。

这两处是本轮完整检查补充发现的，前一次自动审查遗漏了。上面提到的 npm cache 体积告警仍然成立，可以作为不阻断构建的小修正一起处理。

当前相关 CI 已通过。本轮本地做了 YAML 解析、git diff --check 和 Makefile dry-run，也做了上述两个针对性验证；npm 复现环境是 Node 24/npm 11，尚未用 CI 固定版本跑完整的 ARM64 RPM 或 Koji 构建。

[yangdao479]

已补齐并验证以下 review 反馈：

1. ARM64 npm cache：Source1 的填充与消费均使用 --omit=optional --ignore-scripts，避免平台可选依赖及安装脚本触发网络访问；已完成 x64 cache 与 ARM64 platform 离线解析、tsc 验证。
2. V2 RPM 构建入口：scripts/rpm-build.sh agent-sec-core-v2 已接入与 CI package-vendor 共用的 Source1 helper，确保旧入口同样准备 Source0 与 Source1。
3. vendor 体积告警：已改为按完整 VENDOR_STAGING 目录计算，因此 .npm-cache 也会纳入 100 MB 告警。

感谢完整复核。

[kongche-jbw]

Review baseline: 0850fddd09191046d4fb5d4607b6bdae037d8fb7...8cdb54304835e2dd526bbd9bdc39fda05651d352

未发现阻塞问题。

Remaining risks:

• PR CI 未实际运行完整的 ARM64/Koji RPM 构建；当前 ARM64 验证为离线 npm 解析与
  TypeScript 编译。

Verification scope:

• 复核全部 8 个变更文件、上一轮三项修复，以及 release、preview、nightly 和旧 RPM 入口。
• 本地通过 YAML 解析、bash -n、git diff --check 与离线 Make dry-run；PR 的 x64 V2
  Source0/Source1 RPM 构建、安装与 E2E 已通过。

[kongche-jbw]

lgtm thx