[Feature]: 统一 YAML 中远程资源来源的配置模型

[innomentats]

Problem

当前 agent-compose.yml 中，语义相近的 URL 资源来源使用了不同的配置风格：

agents:
  reviewer:
    skills:
      - name: review
        source: git
        url: https://github.com/example/skills.git
        ref: v1.0.0
        path: review

workspaces:
  source:
    provider: git
    url: https://github.com/example/project.git
    branch: main
    path: .

agents:
  reviewer:
    scheduler:
      script:
        url: https://example.com/scheduler.js

目前至少存在三套表达方式：

• Skill 使用 source 作为类型判别，并将 url/ref/path/auth 平铺在条目中。
• Workspace 使用 provider 作为类型判别，并使用 branch/commit/path 描述 Git 定位。
• Scheduler script 将来源嵌套在 script.url 中，仅支持本地文件和 HTTP(S)，不能表达 Git ref/path/auth。

这些配置实际都在描述“从某个来源解析或获取资源”，但字段命名、嵌套方式、认证能力、版本固定方式和加载生命周期不同。这会带来以下问题：

• 用户需要记忆多套相似但不兼容的 schema。
• 很难把已有来源能力复用到其他资源，例如让 Scheduler script 直接读取 Git 仓库中的指定文件。
• 新增来源类型时容易继续复制下载、认证、校验、缓存和凭据脱敏逻辑。
• branch、ref、commit 等版本定位语义不统一。
• URL 是在 CLI apply 时生成快照，还是由 daemon 在运行时解析和缓存，目前只能通过各资源文档分别理解。

Proposal

为 YAML 中可获取的资源定义一致的 source model，并让 Skill、Workspace 和 Scheduler script 采用相同的核心语义。具体嵌套结构可以在设计阶段确定，但至少应统一：

• 来源类型的 discriminator，例如 type 或 source，避免同一概念同时使用 source、provider 和隐式 url。
• url、本地 path、制品内 path 的含义。
• Git ref、branch、tag、commit 的表达及固定到不可变 commit 的行为。
• HTTP/Git 认证字段和环境变量 secret 引用规则。
• 超时、大小限制、redirect、SSRF、路径逃逸、UTF-8 和常规文件校验。
• 内容快照、缓存、刷新和重新 apply 的生命周期。
• 错误路径、canonical YAML 输出和 source identity/hash 计算。

目标能力示例之一是允许 Scheduler script 使用 Git 来源，而不需要手工转换为 provider-specific raw URL：

scheduler:
  script:
    source:
      type: git
      url: https://github.com/example/automation.git
      ref: <commit-or-tag>
      path: schedulers/review.js

该示例只用于说明期望能力，不要求最终 schema 必须采用这一层级。

Compatibility

现有 YAML 形式应继续可用，并在规范化阶段转换成统一的内部 source model。若计划废弃旧形式，应提供明确的迁移提示和兼容周期，避免现有项目配置立即失效。

Acceptance criteria

• Skill、Workspace 和 Scheduler script 共享一套有文档定义的资源来源语义。
• Scheduler script 可以通过 Git URL、ref 和仓库内文件路径获取脚本。
• 私有来源使用环境变量 secret reference，持久化规范和错误信息不泄露凭据。
• 明确定义各资源的解析时机、快照/缓存行为和更新方式。
• 现有配置保持向后兼容，并具有规范化及回归测试。
• 英文和中文 YAML 手册同步更新。