Add platform- and audience-aware tool capability providers

[mostlydev]

Problem

Manifest tools currently express only an executable id, required versus optional, purpose, and installation hints. That is not enough to model several distinct concerns:

• whether a tool is for operators, agents, or both;
• which operating systems and architectures it supports;
• whether it is required for setup, agent launch, a selected skill/profile, or only an optional human workflow;
• whether another executable, API, MCP service, or native application can provide the same capability;
• which tool and skill versions are compatible.

As a result, onboarding may offer or install a tool on a machine where its useful operator workflow does not exist, and manifests cannot express a platform-appropriate substitute. A tool can also be described as optional globally even though it is required only when a particular skill or capability is selected.

Dogfood example

A manifest declares Monologue as an optional tool for reading an operator's notes. A Linux CLI artifact exists, but the relevant operator product/workflow is not available on Linux and the tool should not be required for ordinary agent invocation. The desired behavior is to skip the operator integration on Linux while allowing an API, MCP service, or another provider to satisfy agent-side note retrieval when selected.

A related case appeared with Graphify: the executable installed at 0.9.57 while the manifest-owned static skill remained at 0.9.32. Both were individually valid, but the manifest cannot currently express or validate their compatibility relationship.

Proposed model

Model requirements in terms of capabilities and providers rather than direct executable presence alone.

Possible concepts:

• audience: operator, agent, or both.
• platforms: supported or excluded OS/architecture selectors.
• provides: stable capability ids such as notes.search.
• skill/profile requirements that reference capabilities, with any_of provider semantics.
• providers backed by a local executable, service/MCP surface, native application, or another declared mechanism.
• optional version constraints between a provider and a tool-provided/static skill.
• distinct gates for machine setup, interactive operator workflows, selected agent launches, and contained compilation.

Illustrative shape only:

{
  "capabilities": [
    {
      "id": "notes.search",
      "required_by": ["skill:org:notes"],
      "any_of": ["tool:monologue", "service:notes-api"]
    }
  ],
  "tools": [
    {
      "id": "monologue",
      "mode": "optional",
      "audience": "operator",
      "platforms": [{"os": "darwin"}],
      "provides": ["notes.search"]
    }
  ]
}

The final schema may differ; the important boundary is that platform applicability, audience, requirement strength, and provider choice remain separate dimensions.

Expected behavior

• my tools list reports present, missing, or not applicable with the reason.
• Setup and onboarding do not offer unsupported or irrelevant tools.
• Optional operator-only tools never block agent launch.
• A selected skill/profile fails only when none of its applicable capability providers is available.
• my compile emits the selected role's applicable capability/provider projection deterministically.
• my doctor explains unsatisfied capabilities and lists valid alternatives rather than demanding one hardcoded executable.
• Existing manifests retain their current behavior through backward-compatible defaults.

Acceptance criteria

• Schema validation covers audience, platform selectors, capabilities, alternative providers, unknown references, cycles, and incompatible constraints.
• Tests cover Linux/macOS divergence, operator-only tools, agent-only providers, any_of satisfaction, selected versus unselected skills/profiles, and version incompatibility.
• Onboarding chooses an applicable provider or skips a non-applicable optional capability without treating it as a failure.
• Required tools with no new fields behave exactly as they do today.

Related onboarding ergonomics: #37.