Module client 

TC 去调业务方的 gRPC 分支。

为什么不需要业务方的 proto

这是这一层唯一的技术难点。TC 要能调任意业务服务的任意方法， 但编译期根本不知道对方的 proto 长什么样。

解法是绕开 protobuf 的类型系统：用一个只会搬字节的 BytesCodec 替换 tonic 默认的 prost codec，请求体发裸字节、响应体收裸字节。gRPC 的方法路径 （/包.服务/方法）本来就是运行期的字符串，所以整条调用链都不需要类型信息。

换来的好处很实在：业务方不用为 dtmrs 改接口，已有的 gRPC 服务直接 就能当分支用。DTM 也是这个路子。

请求体发什么

空字节。空的 protobuf 消息对任何 message 类型都是合法的（所有字段取默认值）， 所以不管对方方法的入参声明成什么都能解开。

分支的身份（gid / branch_id / op / trans_type）走 metadata，不走请求体 —— 这正是屏障需要的全部信息。跟 HTTP 那边把它们放 query 参数是一回事。

（每步独立的业务 payload 是后续版本的事，HTTP 那边目前也统一发 {}。）

结果判定

只看 gRPC 状态码，映射见 dtmrs_core::BranchResult::from_grpc。 连不上、超时、UNAVAILABLE 一律是「结果未知」而不是失败 —— 跟 HTTP 侧「超时不等于失败」是同一条命门。

Structs

BytesCodec

只搬字节的 codec —— 让 tonic 在不知道消息类型的前提下完成一次 unary 调用。

GrpcCaller

gRPC 分支调用器，带 channel 缓存。