Capability marketplace part 1: manifest format & local registry

[dgenio]

Parent: #49 | Split: Local marketplace & manifest format

Problem

This is part 1 of #49. Before federated multi-kernel discovery can work, we need the foundational data model: a serializable CapabilityManifest that describes what a kernel offers, and local-registry operations to publish and consume manifests.

Proposed Change

1. Capability manifest model

@dataclass
class CapabilityDescriptor:
    """Public-facing capability description (no internal impl details)."""
    capability_id: str
    description: str
    safety_class: SafetyClass
    sensitivity: frozenset[SensitivityTag]
    parameters_schema: dict | None  # JSON Schema for expected params

@dataclass
class CapabilityManifest:
    kernel_id: str
    version: str
    capabilities: list[CapabilityDescriptor]
    endpoint: str
    trust_level: Literal["verified", "unverified"]

2. Local publish/consume

# Publishing
manifest = kernel.advertise()  # Returns CapabilityManifest

# Consuming
remote_caps = kernel.import_remote(
    manifest=remote_manifest,
    driver=HTTPDriver(base_url=remote_manifest.endpoint),
    trust_policy="most_restrictive",
)

3. Trust policies

• most_restrictive (default): Both local and remote policy must allow.
• local_only: Remote policy ignored.
• remote_deferred: Remote policy checked first.

Acceptance Criteria

• CapabilityManifest is serializable to JSON
• kernel.advertise() produces correct manifest without exposing internal details
• kernel.import_remote() registers remote capabilities in local registry
• Trust policy enforcement works for all 3 modes
• HMAC tokens are kernel-scoped (cross-kernel reuse rejected)

Affected Files

• src/agent_kernel/federation.py (new)
• src/agent_kernel/models.py (CapabilityManifest, CapabilityDescriptor)
• src/agent_kernel/kernel.py (advertise(), import_remote())
• tests/test_federation.py (new)
• docs/federation.md (new)