getPluginInfo().capabilities 是硬编码全量列表，子插件无法据此做能力探测

[SongshGeo]

现象

README-ZH 建议子插件「想兼容老版本宿主，就在调用前先查 capabilities」，我们（Inputs Bell）也照做了：ctx.ai.available() = getPluginInfo().capabilities.includes('llm-invoke')。

但对着 0.4.7 release 的 main.js 读下来，这个列表是常量，跟激活状态、跟宿主自己有没有配好密钥都没关系：

function yi(l){
  const e=it(l).verificationWorker?.getLicenseData?.()??null;
  return {id:...,name:...,version:...,schemaVersion:$s,
    isActivated:!!e?.is_active,
    capabilities:["account","config","plugin-info","llm-invoke","llm-credentials","activation","download-ticket"]}
}

为什么这是个问题

capabilities 目前只能回答「这个宿主版本认不认识这些 scope 名字」，不能回答「现在调用会不会成功」。而后者才是子插件需要的：

• llm-credentials 按 README §3 是卡许可证的（requestLLMCredentials 里 await We(this.plugin) && await this.ensureGranted(...)）。未激活用户那里它必然返回 null，但 capabilities 仍然列着它。子插件想「没这个能力就别打扰用户」，结果还是会弹一次同意框，用户点了允许，然后拿到 null。
• llm-invoke 对未激活用户是有限额的（每日 5 次），耗尽后返回 errorCode: 'quota-exhausted'。这个有 errorCode 可认，问题不大。

也就是说：真正需要「先问一句、别白弹框」的那个 scope，恰恰是 capabilities 答不了的。

建议

三选一都行，我们这边跟随：

1. capabilities 改成当前实际可用的列表（未激活时不含 llm-credentials）。语义最直观，但会和「探测宿主版本认不认识某 scope」的用途冲突。
2. 保留 capabilities 表示「本版本支持的 scope」，另加一个 availableCapabilities / entitlements 表示当前可用。
3. 至少在 README 里写明 capabilities 是静态版本能力而非授权/激活状态，免得子插件像我们一样按后者用。

无论哪种，isActivated 已经在同一个对象里了，子插件也可以自己组合 —— 但那要求每个子插件都重新推导一遍「哪些 scope 卡许可证」，这个知识应该留在宿主。

环境

• 宿主：0.4.7（release 附件 main.js）
• 子插件：Inputs Bell (paper-in-bell)