[P2][架构] market 与业务插件双向依赖，跨版本共享能力仍由插件私有函数承载 #159

范围与基线

第二轮架构审查；只讨论模块职责、导入方向和公共接口归属，不评价 SQL、结算算法或具体 handler 的正确性。

固定基线：476e64f04ed1d9c7dcab4a41c4f3cdb72faad6a7。Refs #85；与 #71/#72 的功能验收分别跟踪。遵守 docs/ARCHITECTURE_REUSE.md：保留现有市场、历史操作版本和单一受保护记账路径，不再造一套市场实现。

结构证据

• market/orders.py 的导入区：新 checkout 模块直接导入 plugins.orders 的 _order_id/_row/_subject/_view/_viewer，以及 plugins.store 的 _body/_listing/_package_row 和 plugins.money._post_transfer。
• plugins/orders.py 的导入区：旧 checkout 插件又依赖 market.escrow.EscrowEngine/validate_policy。
• market/email.py 同样导入 plugins.orders._row/_subject；market/escrow.py 依赖 plugins.money._balance/_post_transfer。

market.orders/email ──> plugins.orders/store/money 的内部辅助函数
plugins.orders     ──> market.escrow
market.escrow      ──> plugins.money

这是包级双向依赖和共享接口所有权不清；不据此声称存在导入时崩溃、重复扣款或安全漏洞。

架构问题

market/ 已作为跨版本市场能力的组织位置，但共享的订单读取、主体检查、投影及记账能力仍散落在具体插件内部。结果是新版本业务依赖旧入口的内部结构，旧入口又依赖新抽出的市场模块。

下划线本身不是问题。问题是这些函数实际已经承担跨模块公共接口，却没有与具体版本的 schema、注册及兼容行为分开。后续清理旧入口、调整订单投影或添加一个操作版本时，很难从模块边界判断哪些调用者会被连带影响。

保留多个已发表协议版本是必要兼容要求，不等于需要让新版本继承旧入口的私有组织方式。

建议边界

按职责建立单向关系，而非按新旧版本另造实现：

旧/新版本的操作注册、参数适配、响应兼容
                 ↓
     明确公开的市场用例与共享查询/投影
                 ↓
      唯一受保护记账路径、元数据事务

只抽取确实被跨模块调用的稳定能力，普通函数即可；明确其所有者、参数、事务要求与返回结构。版本特有的签署内容、字段编码和响应适配留在对应版本边界。公共记账能力不能通过重命名变成任意调用的无约束扣款接口。

验收

• 列出上述跨模块依赖的所有者和允许调用方向；market 中共享业务能力不再依赖具体插件入口的私有函数。
• 新旧操作适配共同调用一份业务能力；不能复制 _row/_view/_post_transfer 来消除导入，也不能只去掉下划线而保留混合职责。
• 旧 orders.buy@1/@2/@3 的 schema、签署字节、ID、receipt 和明确结算政策保持原义；响应投影差异仍由各版本明确负责。
• 继续只有一条受保护的账项提交路径；escrow 账户类型、授权、锁顺序、原子性及恢复边界不因分层调整而改变。
• 对受影响模块增加导入边界或公共接口检查，并保留各版本市场/交付/恢复回归；无需全仓搬目录、拆微服务或新建 Manager/Factory/Repository 层级。

本项不要求部署、操作真实资金或关闭市场功能总体验收。