devapp 实际执行的 /usr/local/bin/workspacex-deploy 是 #2296 之前的旧副本，platform skill backfill 从未真正跑过

## 真实证据（不是猜测）

用户反馈：chat 里 `#` 挂载候选、composer 挂载浮层都看不到 `pdf-create`（`docx-create`/`xlsx-create` 同理）。追查代码本身（`GET /skills` → `listSkills` → `pg-skill-contract-repository.ts` 的 `listAll`）确认查询逻辑正确——`WHERE (sk.org_id = $1 OR sk.org_id = $2)` 已经把 `PLATFORM_ORG_ID` 纳入，权限判定（`visibility-scope.ts`/`permission-decision.ts`）也不按行的 `org_id` 与请求者 `orgId` 比对。代码没有 bug。

## 根因：devapp 上实际执行的 `deploy.sh` 是一份没刷新过的旧副本

`.github/workflows/backend-gates.yml` 的 deploy job 自己写明：

> 走 `/usr/local/bin` 的副本，不是仓库里那份——sudoers 只许这一条路径。

`/usr/local/bin/workspacex-deploy` 由 `provision.sh` 第 7 步 `install` 上去，**不会**随每次 `git push` 自动刷新——只有人手动重跑 `provision.sh`（或单独重跑第 7 步）才会更新。

实测（本次会话，SHA `13f771f3`，即 [#2328](https://github.com/boardx/workspacex/pull/2328) 的合并提交）：那次 deploy 的真实 CI 日志（`gh api /repos/boardx/workspacex/actions/jobs/98965190839/logs`）里，步骤顺序是：

```
══════ 4h. deep-agent-service（...） ══════
...
══════ 5. 构建前端 ══════
```

`4i. 平台组织补种` 与 `4j. 平台级官方 skill 补种`（[#2296](https://github.com/boardx/workspacex/pull/2296) 加的两步，`git merge-base --is-ancestor` 确认已经在 `13f771f3` 的祖先链里）**完全没有出现在日志里**——不是执行了但没输出，是这两步在跑的那份 `deploy.sh` 里根本不存在。devapp 上 `/usr/local/bin/workspacex-deploy` 是 #2296 合并**之前**装的旧副本，此后的每一次真实部署都在跑那份旧脚本，`backfill-platform-skills.ts` 从未在 devapp 上被调用过一次。

这与 #2296 自己修的那个问题是**同一类**，但换了一层：#2296 修的是"合并后忘了手动 SSH 上去跑一次 backfill"，而这次是"合并后忘了手动 SSH 上去刷新那份特权副本"——`provision.sh` 自己的头注其实已经预见到这类漂移（"以后给 deploy.sh 新增依赖时，这里必须同步加一行 install"），但没有机制强制这件事发生，只能靠人记得。

## 修复需要的动作（需要真实 devapp SSH 访问，本次会话没有）

在 devapp 上以有 sudo 权限的账号重跑 provision 的第 7 步（或整个 `provision.sh`，幂等）：

```bash
sudo install -o root -g root -m 0644 /path/to/repo/.harness/scripts/vm/deploy-readiness.sh /usr/local/lib/workspacex-deploy-readiness.sh
sudo install -o root -g root -m 0644 /path/to/repo/.harness/scripts/vm/deep-agent-lib.sh /usr/local/lib/workspacex-deep-agent-lib.sh
sudo install -o root -g root -m 0755 /path/to/repo/.harness/scripts/vm/deploy.sh /usr/local/bin/workspacex-deploy
```

刷新后**不会**自动补跑一次——下一次真正的部署（下一次 push 到 main，或手动 `sudo /usr/local/bin/workspacex-deploy `）才会真正执行 4i/4j，把四个官方 skill 种进 `PLATFORM_ORG_ID`。

## 值得考虑的后续（不在本 issue 范围内，只是如实记录）

`/usr/local/bin/workspacex-deploy` 与仓库版本之间没有任何漂移检测——这次要不是人类实测撞见，不会有任何信号。一个可能的方向：deploy job 跑之前先比对 `sha256sum /usr/local/bin/workspacex-deploy` 与仓库 `deploy.sh` 的哈希，不一致就先报警而不是静默跑旧版本。这是设计决策，需要人类裁决要不要做、怎么做，这里只记录观察到的缺口。

Start with .github/workflows/backend-gates.yml and the step 7 installation in .harness/scripts/vm/provision.sh, then compare the repository deploy.sh with the installed copy on devapp. Refresh the listed deploy files with the provision step and trigger the next deployment. Done means the logs show steps 4i and 4j and the platform skills are available.

Written by the indexing model from the issue text.