feat(#65 P6): resolve Policy expression asymmetry between RCM and gRPC

[yzxoi]

Problem

Two fundamental architectural asymmetries (Issue #65, P6):

1. RCM syntax has no way to express Policy logic — policy = "captain" is just a string name, no customization hooks
2. gRPC takes the opposite approach — no Policy at all, client drives step-by-step manually

The asymmetry means:

• Custom policies can only be added in Rust code, not declared in .rcm
• gRPC clients must re-implement Policy decision logic from scratch
• There is no shared "Policy spec" that both paths could consume

Questions to resolve

• Should RCM gain a policy declaration DSL (decision rules, phase ordering, retry params)?
• Should gRPC gain a Policy configuration (e.g. OpenRequest gets a policy spec)?
• Or should both converge to a simpler model — remove Policy from RCM entirely, make gRPC the only decision path?

This is an HITL issue — requires design discussion before implementation.

Parent: #65

[github-actions]

分类与优先级判断

• 分类：feature（架构级特性 / 设计议题）
• 优先级：P2（需设计讨论后方可实施）

是否疑似重复
经检索未发现明显重复 issue。相关议题：#65（父 issue，语义不一致总览）、#67（对称性原则），但与本 issue 不构成重复。

一句话总结
该 issue 指出 RCM 配置语法与 gRPC 接口在 Policy 表达能力上存在架构不对称，前者仅支持字符串名称而后者完全缺失策略层；需设计讨论以决定是否引入策略 DSL、为 gRPC 增加策略配置，或彻底移除 RCM 中的 Policy 概念以统一决策路径。