feat(installer): tighten workspace bootstrap policy

[Li-Sanze]

概要

这个分支收紧了 workspace bootstrap 的策略边界，把“什么时候允许首次写入 .sopify-runtime/、什么时候必须停下来确认、什么时候应该直接 fail closed” 明
确下来，并让 installer 与 runtime gate 对这些规则保持一致。

目标不是增加流程，而是避免在根路径选择、host/payload 归属不明确、以及 first-write 场景下发生静默写入或错误 bootstrap。

变更内容

• 收紧首次写入授权规则：只有显式命令（如 ~go、~go plan、~go init）才允许触发首次 bootstrap
• 为 ~go init 建立显式确认语义，不再和普通执行命令混在一起
• 对 nested repository / monorepo 场景补上 activation root barrier：根路径不明确时先停下来确认，而不是直接写入推测路径
• 对 no-write / explain-only / non-interactive 等场景补上 fail-closed 或 checkpoint 行为，避免错误进入 bootstrap
• 收紧 host 与 payload 的选择规则：当存在多个 payload 候选或 host/payload 不匹配时，要求显式指定，避免跨 host 误选
• 关闭 bootstrap ignore policy 的闭环：workspace bootstrap/update 时同步维护 .gitignore / ignore policy，而不是只写 stub 不维护忽略策略
• 明确 workspace stub 是 thin stub：helper 入口应从 selected global bundle 解析，不再要求 workspace stub 自带完整 helper contract
• 调整 installer 文案和入口说明：--workspace 仅保留给 maintainer / internal prewarm，默认用户路径是先完成全局安装，再在首次项目触发时由 runtime
  gate 完成 bootstrap
• 同步更新 blueprint / project 文档，使运行时分层和 bootstrap 契约描述与当前实现保持一致

为什么要做

此前 bootstrap 相关行为在几个边界上还不够硬：

• 首次写入授权和普通咨询请求之间边界不够清晰
• monorepo / nested repository 下可能默认写到推测出来的根目录
• 多 host / 多 payload 场景下，payload 选择容易依赖隐式顺序
• workspace stub、global bundle、installer 文案三者的职责边界还不够一致

这些问题本质上都会导致同一种风险：系统在“上下文还不够确定”的情况下，过早写入或选错 bootstrap 目标。

这次改动把这些边界显式化，优先保证 bootstrap 的可解释性和可恢复性。

验证情况

• tests.test_installer 已补充并通过相关策略覆盖
• tests.test_runtime_gate 已补充并通过 root confirm、host/payload 选择、legacy helper 边界等场景
• tests.test_installer_status_doctor 已覆盖 workspace / payload 诊断结果
• tests.test_distribution 已覆盖分发与输出面相关回归
• scripts/check-prompt-runtime-gate-smoke.py 已补上 root confirm checkpoint smoke
• scripts/check-runtime-smoke.sh 已补上 thin stub 与 selected bundle helper contract 的 smoke 校验