1. 合入背景

为 kv-conductor 的 /query 与 /query_by_hash 增加 MessagePack 编解码支持，并在 Coordinator 端到端打通（ConductorApiClient.query_conductor 默认走 msgpack）。长上下文（1M/5M token）场景下，KV 亲和性查询的请求体积与编解码耗时显著下降。

借鉴 Mooncake conductor #3258 的 Content-Type 分派方案；与 KV Conductor 的前缀索引能力（#338 对应的自研 kv-conductor）配套演进。

关联 ISSUE：#455

2. 修改内容

1. kv-conductor（Rust，motor/kv_conductor/）
   • /query、/query_by_hash 按请求 Content-Type 分派：application/msgpack → rmp_serde 解码请求，响应/错误/空结果用 rmp::encode 手工编码；其他 Content-Type 走原 JSON 路径（行为不变）。
   • 响应侧手工编码的原因：QueryResponse 使用 #[serde(flatten)]（tenants 展开到顶层 map），msgpack 序列化器不支持 flatten——手工编码保证 msgpack wire 形状与 JSON 逐字节等价，并有单元测试（rmpv→serde_json 结构化对比）守护。
   • QueryRequest / QueryByHashRequest 增加 Serialize（原仅 Deserialize）。
2. Coordinator（Python）
   • ConductorApiClient：新增 encode_query_msgpack / decode_query_response_msgpack（msgspec），query_conductor() 按 kv_conductor_config.query_encoding（默认 "msgpack"）分派；响应按服务器 Content-Type 解析（msgpack → msgspec，否则 JSON），旧版 JSON-only conductor 自动兼容，无需配置切换。
   • SafeHTTPSClient 新增 post_bytes()（原始 body POST）。
   • KvConductorConfig 新增 query_encoding 配置项。
3. 测试
   • Rust：单元测试 120（新增 msgpack 往返、wire 形状等价、Content-Type 嗅探、错误/空结果编码）+ 集成测试 20（新增 msgpack/JSON 查询结果一致、msgpack /query_by_hash、404/400 错误路径按请求编码返回）；cargo clippy -D warnings、cargo fmt 通过。
   • Python：api_client 44（新增 msgpack wire 格式断言、json 配置路径、legacy JSON 响应 fallback）、coordinator 模块 1155 全过。
   • 性能验证使用临时 benchmark 脚本（真实 conductor 进程 + client 真实编解码路径），bench 属验证工具未随 PR 上库。

3. 资料变更

涉及：

• docs/zh/user_guide/configuration/config_reference.md：新增 kv_conductor_config.query_encoding 配置说明。
• skill reference（.agent/skills/motor-dev/references/coordinator.md、kv-conductor.md）：新增 msgpack 编解码章节与端到端数据，并修正两处过时内容（服务端加权评分模型已移除、src/indexer.rs → src/indexer/ 目录）。

4. 接口变更

涉及（客户面可见）：

• POST /query、POST /query_by_hash 新增 Content-Type: application/msgpack 请求编码支持，响应随请求编码返回（JSON 默认行为不变，向后兼容）。
• Coordinator 配置新增 kv_conductor_config.query_encoding（默认 "msgpack"；对接旧版 conductor 可配 "json"）。

5. 测试结果

性能收益（真实 kv-conductor release 进程 + Coordinator client 真实编解码路径，best-of-5，DeepSeek V4 风格长上下文）：

=== 1M tokens（block_size=128）===
step     JSON          msgpack      提速       请求体积
encode   29.92 ms      2.89 ms      10.4x     6.65MB -> 2.99MB (-55%)
HTTP RTT 45.63 ms      12.07 ms     3.78x     (客户端序列化+服务端XXH3哈希/树匹配/序列化+网络)
TOTAL    45.63 ms      12.07 ms     3.78x

=== 5M tokens（block_size=128）===
encode   149.8 ms      14.4 ms      10.4x     33.3MB -> 14.9MB (-55%)
HTTP RTT 220.5 ms      41.9 ms      5.26x
TOTAL    220.5 ms      41.9 ms      5.26x

• 5M 上下文单次查询省 ~178ms，1M 省 ~34ms；请求体积减半（网络传输同步受益）。
• 收益来源：客户端 msgspec 编码（10x）、服务端 rmp 解析 vs serde_json（RTT 内体现）、传输字节减半。

短上下文覆盖（1 ~ 16K tokens，纯编解码，msgspec vs json.dumps/loads，best-of-20000）：

tokens | json enc    msgpack enc | json dec    msgpack dec
     1 |    1.07us       0.12us  |    1.19us       0.21us
    64 |    2.83us       0.27us  |    2.94us       0.51us
  1024 |   26.44us       2.31us  |   26.44us       7.96us
 16384 |  437.67us      32.82us  |  430.86us     148.58us

• 全长度区间（1 ~ 16K token）msgpack 均更快：1 token 时亦快 ~9x（编码 0.12us vs 1.07us）；
• 无临界点、无负收益——msgspec 为纯 C 实现，固定开销（~0.1-0.2us）低于
  json.dumps/loads 的固定开销（~1-1.2us），短上下文（普通对话场景）同样占优；
• 默认 query_encoding: "msgpack" 在短/长上下文下均无回归。

功能测试：

• cargo test：120 单元 + 20 集成全过；
• bash tests/run_tests.sh tests/coordinator/：1155 用例全过；
• pre-commit 全量通过（ruff/pylint/bandit/cargo clippy/fmt 等）。

测试场景：单元（编解码往返/等价性）、集成（HTTP Content-Type 协商、错误路径、JSON 兼容）、端到端（1M/5M 长上下文性能）。精度/显存不涉及（无模型运行）。

6. CheckList

• 代码注释完备
• 正确记录维测日志
• 是否有UT用例（120 Rust 单元 + 20 集成 + 44 Python 单测）
• 若涉及多线程场景，考虑了并发场景，不存在死锁问题（查询路径只读锁语义未变，msgpack 编解码为无状态纯函数）