pluginInventory: provenance and change events

[yohurm]

Context

pluginInventory/list is a point-in-time read with no provenance: it cannot say which bundle or patch layer introduced a row, and it emits no change events, so browser surfaces must poll.

Proposal

Add per-entry provenance (bundle layer / profile patch / receipt-style source) and a subscription or forwarded events for mount/unmount/phase changes.

Why

YoDsh merges inventory with profile manifests and receipts to reconstruct provenance client-side; a first-class field would remove the reconstruction and let panels update live instead of polling.

[zoahdev]

核验通过（HEAD 99f6f02）：packages/extensions/ui-cordis 的 inventory 是客户端快照 store（createCordisInventory：getSnapshot + subscribe + refresh）——"point-in-time 读 + 浏览器轮询/刷新"属实。

三点评述（其中两点是跨提案综合）：

1. provenance 字段正好是 #3192 CHA2A 的宿主侧数据源

你提的"bundle layer / profile patch / receipt 样式来源"三种 provenance，与 CHA2A 的分层签名一一对应：bundle 层 = 安装单位（内容指纹的验证单元）→ L1/L2；receipt 样式来源 → L3 发行认证（did:store 上架记录）。pluginInventory 补上 provenance 后，CHA2A 的认证等级在宿主里就有了一等公民的可读数据源——两个提案是同一层级的两个面（身份/信任 vs 运行时可见性），建议互相引用。

2. 部分 provenance 数据其实已存在，先"暴露"再"新增"

profile manifest 的 dsh.profile.bundles + patch 层已经由 reconcilePlugins（apps/cli/src/plugin.ts）按安装状态维护——"哪一层引入的"这个信息宿主侧已有，inventory 只是没暴露。建议分两步：先暴露已有字段（低风险、纯增量），再做 receipt 样式来源（需要新增数据结构）。

3. 变更事件建议走统一接缝，别单独做

mount/unmount/phase 变更事件与 #3191（会话事件注册）是同族需求。如果按 #3167 的建议先设计统一的 out-of-tree capability registry（事件 + Remote + 请求策略共享注册语义），pluginInventory 的订阅可以直接挂进去，避免浏览器继续轮询的同时也避免每个 surface 各做一套事件机制。

顺带一个注册表侧经验：dsh-subscribe 已在条目级记录 source（verified=zoahdev 审计 / community=awesome-dsh-plugin 镜像）——store 层 provenance 已实现，host 层 pluginInventory 补上后两层就能对齐（同一插件在 store 和 host 看到同一来源语义）。