[P2][架构] NativeGitStore 混合仓库操作与 HTTP 适配，Git/HTTP/SSH 模块形成双向依赖 #163

范围、基线与去重

本项只检查代码树、模块导入、类的方法职责及接口归属，不分析 Git 命令、授权条件、流式处理或引用发布算法的实现正确性。

固定基线：476e64f04ed1d9c7dcab4a41c4f3cdb72faad6a7；提交前已再次核对 main。审查的完整 src 树与该提交的 Git tree 6f20adb3f4eaad0c5140c0bf05abdf2fabbcfe8e 一致。

已对照现有 issue 正文、相关评论及新增 #156–#162：

• 混合内容卷容量预算与实际存储拓扑的崩溃恢复验证 #80 跟踪真实 Git/LFS 客户端、存储一致性与 hosting 功能验收；本项不重复列这些功能缺口，而是报告其共享 Git 类与协议模块的职责耦合。
• [P2] 跨模块代码质量与测试债：拆分长路径、统一不变量 #85 是跨模块收敛总项，已记录 http/http_routes 拆分；本项不是按旧文件大小再次要求拆 HTTP，而是指出当前拆分之后仍存在的具体依赖环。
• [P2][架构] 工具执行端口与实际 runner 分层不清，结果类型反向依赖 worker 编排模块 #160 处理工具 runner 的端口与 ToolResult 归属；即使完成该项，下面的 Git/HTTP/SSH 依赖仍然存在。本项不重新设计 worker 或工具端口。
• [P2][架构] OperationExecutor 反向依赖插件与 Application，执行内核缺少清晰的依赖边界 #156–[P2][架构] market 与业务插件双向依赖，跨版本共享能力仍由插件私有函数承载 #159、[P2][架构] 独立 hosting 进程复用完整写服务运行时，缺少只读角色的能力与密钥边界 #161–[P2][架构] Application 同时承担服务装配与凭据一次性交付业务，身份生命周期缺少独立职责归属 #162 的执行器、数据库继承、客户端、市场、hosting 装配和凭据交付问题不在本项范围。

Refs #85；保持权威设计第02、09、11、13、14章的模块化单体与统一执行约束。

结构证据

1. 同一个类同时拥有仓库操作和 HTTP 请求/响应职责

extensions/repositories.py:108 的 NativeGitStore 同时声明两组方法：

仓库能力：
  create(id)                           L310
  refs(id, *, after='', limit=100)      L335
  import_bundle(id, bundle_path, ...)   L352
  update_refs(id, changes)              L372

HTTP 适配：
  http_lfs(request, repo_id, suffix, ...) L189
  http(request, repo_path, suffix)       L384
  http_push(request, rid, suffix)        L439
  _http_push_receive(request, ...)       L508

该模块在第19–20行直接导入 Starlette 的 ClientDisconnect、Response、StreamingResponse。因此不是一个名称不够准确的问题，而是协议对象已经进入跨入口复用的仓库组件。

2. HTTP 入口与仓库模块形成反向导入

• transports/http_routes.py:499–517 在 Git/LFS 路由中导入 NativeGitStore。
• extensions/repositories.py:189–191 又从 transports.http 获取 body_bytes/json_response；第439–441行 同样依赖其响应/错误转换。
• transports/http.py:15–25 从 http_routes 导入这些公共辅助函数。

transports.http_routes
        ↓ 导入 NativeGitStore
extensions.repositories
        ↓ 导入 HTTP 响应/请求辅助函数
transports.http
        ↓ 导入并转出辅助函数
transports.http_routes

3. HTTP 与 SSH 共享的 Git 发布能力也没有中立归属

extensions/ssh_git.py:22–26 导入 NativeGitStore 及仓库限制；反方向上，repositories.py:582 在 HTTP 接收路径中导入 ssh_git.guarded_command。

repositories 的 HTTP 接收路径 → ssh_git.guarded_command
ssh_git                      → repositories.NativeGitStore

其中部分是函数内延迟导入。这里报告的是静态依赖与职责所有权，不把依赖环直接推断成启动失败、循环导入异常或权限漏洞。

架构影响

HTTP 报文/响应、Git 仓库操作、跨协议的受控发布具有不同的变化原因，却集中在同一类和互相依赖的模块中。SSH 要复用仓库能力时也依赖包含 HTTP 表示的实现单元；HTTP 要复用受控 Git 发布时，又依赖以 SSH 入口命名并持有其接线职责的模块。

仅从类和包边界无法清楚判断哪些是 HTTP 专属，哪些是 SSH 专属，哪些是所有入口必须共同使用的发布约束。后续替换 HTTP 框架、调整某个入口或单独测试仓库接口，会受到不相关协议层的组织方式影响。这里没有测量性能，也不声称现有授权或原子发布已失效。

建议边界

保持现有仓库、进程、OperationExecutor、EffectJob 和存储后端，不拆微服务，也不为 Git/LFS 每个名词新建 Service/Repository/Factory。

在现有模块内做小范围职责分离：

HTTP 适配             SSH 适配             bundle 操作/既有 worker
    \                    |                         /
          共同的受控 Git 用例与发布能力
                         ↓
              Git/LFS 仓库与内容存储能力

• HTTP 请求解析、状态码和 Starlette Response 留在协议适配一侧；共享仓库能力接收明确数据/流或引用，不认识 HTTP Request/Response。
• 已被 HTTP 与 SSH 共同复用的 guarded publication 机制给出明确所有者，两个入口分别调用它，不互相导入对方的适配实现。普通函数和小型记录即可，不要求新的抽象类体系。
• 共用机制不能复制授权、另开提交路径或绕过当前任务检查。需要的当前主体、事务、发布条件和输入/输出依赖应明确，而不是通过移动/重命名隐藏原有耦合。

验收条件

• 给出调整前后的 Git/HTTP/SSH 模块依赖与公开接口；共享仓库/发布能力不再依赖 HTTP 应用/路由模块或 SSH 专属入口实现。
• NativeGitStore 或其保留的仓库组件不再同时拥有 HTTP handler；不以换类名、复制辅助函数或把同样职责藏到全能上下文中代替分离。
• HTTP、SSH、bundle 继续使用同一份适用的发布约束和真实存储，不产生平行授权、LFS 内容或任务状态机。
• 增加覆盖函数内导入的边界检查，以及共享仓库能力不加载 HTTP/SSH 适配器的装配/契约测试。不能只检查顶层 import 或文件行数。
• 保持公开路径/操作版本/签署字节/ResourceRef/receipt 不变；普通资源和 Git/LFS 路径的只读约束不变，写入仍通过既有受控执行入口。
• 保留当前授权、恢复 quarantine、attempt/state/deadline 栅栏及 Git/LFS/多 ref/HTTP/SSH/bundle 的既有回归。不据此宣称 混合内容卷容量预算与实际存储拓扑的崩溃恢复验证 #80 的完整现场验收已经完成。

本轮未修改代码或运行功能测试；这是基于固定源码结构的架构问题，不授权生产仓库迁移、部署或权限变化。