docs(rfc): propose source plugin framework

[Junkrat77]

Which issue or RFC does this PR close?

Proposes a new Source plugin framework RFC; no issue is closed.

• English RFC
• Chinese RFC

Rationale for this change

Users need to develop custom Source plugins or use existing ones to support different data types, Projections, and collection logic without modifying PowerContext core. Applications and hosts need a common way to discover and use built-in and custom Source capabilities.

What changes are included in this PR?

Adds matching English and Chinese RFCs covering:

• write: Server loads custom Definition and Projection implementations and synchronously saves complete content supplied by the caller.
• collect: plugins control collection timing and reuse the existing Worker, submission, and checkpoint pipeline.
• Public Source MCP call flows, plugin loading, and the responsibilities of Server, the plugin management service, plugin instance Runtime, and existing Worker.
• Target identity and repeat-call behavior, storage ownership, lifecycle and recovery, upgrades, and existing PC Access authorization.

The RFC includes architecture and flow diagrams. Deployment guides and runnable plugin examples will accompany implementation.

Are there any user-facing changes?

Documentation only; no changes to runtime behavior or persisted data formats.

How was this change tested?

• uv run prek run -a: all hooks, including type checking, passed.
• git diff --cached --check: passed before committing.
• Compiled both final RFC documents as MDX.
• Reviewed English/Chinese consistency.

Validation covers documentation only; the proposed functionality was not tested at runtime.

AI usage statement

Codex assisted with drafting, editing, and reviewing the bilingual RFCs based on the contributor's design decisions and feedback.

[AlexStocks]

[P2] RFC 缺少模板要求的收尾章节，而它们恰好承载这个提案最需要的论证

对照 docs/en/rfcs/0000_example.md，本 RFC 只有 Summary / Motivation / Guide-level / Reference-level，缺 Drawbacks、Rationale and alternatives、Prior art、Unresolved questions、Future possibilities 五个章节。双语结构完全对齐（这点做得好），但两边同时缺。

这些不是格式仪式——对本提案恰好是最需要的部分：

1. Drawbacks / 安全边界：框架要在 Server 侧加载并执行第三方插件代码（插件实例 Runtime 甚至跨机连接），这引入了任意外部代码执行面。文末「Permission responsibilities / Credentials」两节覆盖了授权与凭据，但没有一处集中讨论信任边界：插件代码以什么身份运行、崩溃/恶意行为的爆炸半径、是否需要进程隔离或 capability 降级。这是评审人必然会追问的问题。
2. Rationale and alternatives：为什么不沿用 feat(sources): add Source Definition and Connector contracts #1400 已有的 Source Definition 注册表 + MCP 提交管线、只把「发现/加载第三方实现」做成一个薄扩展，而要引入独立的插件管理服务 + 实例 Runtime + 目标管理这三层？现有文中的论证散落在各节，缺少一个集中的方案对比表。
3. Unresolved questions：插件签名/供应链校验、插件 API 的版本兼容承诺、collect 插件对 Server 稳定性的影响上限等，都还没交代由谁在何时决定。

作为 draft 这些可以后补；建议在转 Ready 之前补齐，尤其第 1 点。语言与结构质量本身没有问题。