feat: trusted release keys setting; drop the duplicate release registration route [CI]

The panel now lets the deployer decide which release keys it trusts. The
official CI key is built in and always trusted; an own P-256 public key can be
added (off by default, the private key is rejected) so manifests signed with it
are accepted too. Removing it drops the manifests only it signed. Changes are
audited and need update.confirm.

Admin UI: System > Trust > "Trusted release keys" with a collapsible guide on
generating a key pair and signing a manifest with openssl.

Registration now has one path, POST /api/release/offer (no token, signature
verified). The admin POST /releases route, the release.publish capability and
the ci-release preset are removed.

docs/deployment.md

@@ -315,6 +315,8 @@ sh packaging/update/install-updater.sh agent --user \
 
 发布私钥只放在 Woodpecker 的 `release_signing_key` secret；发布公钥位于 `packaging/update/release-key.pub.pem`。`RELEASE_API_URL` 指向面板，CI 把签名清单 POST 到 `/api/release/offer`：这个入口不需要令牌，面板用内嵌的发布公钥验签，签名无效就拒绝，所以 CI 不需要在面板里持有任何凭证（清库或重装后照常登记，也没有长期令牌可偷）。面板保存并转发签名清单，Agent/Probe 将它与更新请求写进配置 volume；更新器验签后才调用容器引擎和 systemd。管理端仍能看到可更新、更新中、已回滚和无效清单状态。纯二进制更新器尚未实现。
 
+**自有发布密钥**（自己构建、自己发布的部署；默认关闭）：管理端「系统 → 信任 → 可信资产来源」。官方 CI 发布密钥始终信任，不能关；另外导入**自己的发布公钥**（P-256 的 PEM，面板拒绝私钥，私钥留在你自己的机器或 CI 密钥库）之后，用你的私钥签的清单也会被面板登记和分发。签名方法：`openssl dgst -sha256 -sign release.key -out manifest.sig.bin manifest.json`，再 `base64 -w0` 得到签名；清单是一行扁平的 JSON（字段见 `ci/release-manifest.sh`），交给面板用 `POST /api/release/offer`，或者像官方那样放进你镜像仓库里的清单镜像。节点宿主机的更新器只认本机的公钥文件，所以用你自己的密钥发布时，还要把你的公钥放进这些节点的 `release-key.pub.pem`，并且清单里的 `image` 必须等于它本机配置的镜像仓库。停用自有密钥时，只有它签过的已登记清单会被丢掉。
+
 **换发布密钥**（泄露或定期轮换，不用重装节点）：
 
 1. 生成新密钥对；CI 给发布流水线加 `RELEASE_NEXT_KEY`（新公钥 PEM），仍用旧私钥签名。清单里会带 `next_key`（SPKI DER 的 base64）。