feat(spec): add Dependencies official extension (resolves #63)

[marianogonzalez]

Summary

This PR resolves #63
(declare an artifact's downstream dependencies) by adding an official
extension — https://ai-catalog.org/extensions/dependencies — rather than a
core Catalog Entry field.

An artifact often relies on other artifacts to function: an agent calls a
downstream MCP server, a skill requires a specific tool, a plugin ships a
companion agent. The extension lets a publisher declare those edges on an
entry so a consumer — an agent planner or a governance tool — can answer
"can I use this artifact?" (do I hold the credentials its dependencies
require?) and "what breaks if I decommission artifact X?" before
invoking or deploying anything.

Implementing this as an extension honors ADR-0002
(which deferred a core dependency field over an unresolved AND/OR ambiguity)
rather than reversing it: the core schema stays minimal and dependency-free,
and the sanctioned extensions mechanism carries the capability. Because the
extension is additive and unrecognized extensions are ignored, it needs no
specVersion change — a catalog carrying it remains a conformant 1.0
document.

Changes Included

1. adr/0021-dependencies-extension.md (new) — records the decision to
   implement Spec Proposal: Dependencies manifest #63 as an official extension, resolves the AND/OR blocker from
   ADR-0002 by placing the two relations on separate structural axes
   (required[] = AND, anyOf group = OR), and documents the reconciliations
   below.
2. adr/0002-defer-entry-dependencies.md — status/update note clarifying
   that the deferred capability was later delivered as an extension by
   ADR-0021 (the core-schema decision itself still stands).
3. specification/ai-catalog.md:
   • Registered the extension in the Official Extensions list alongside
     metadata.
   • Added the Dependencies Extension section: value structure
     (required / optional), the Dependency object (identifier REQUIRED;
     type, versionConstraint, credentialPropagation, purpose
     OPTIONAL), the anyOf Dependency Group, resolution semantics, an
     example, and a normative CDDL schema block.
   • Added a Dependency Confusion and Malicious Dependencies security
     subsection and a note under Catalog Poisoning; extended the multi-artifact
     example and the MCP / Claude Plugins mapping appendix.
4. specification/examples/ai-catalog.json — the canonical example's
   finance agent now declares a required MCP dependency and an optional A2A
   dependency.
5. Developer docs — a new annotated example
   (docs/examples/agent-with-dependencies.md), an authoring section in
   Creating a Catalog, a pre-flight dependency-check section in Consuming
   Catalogs, plus cross-links and a nav entry.

Reconciling the original proposal

The proposal in #63 predates several current conventions; the extension uses
today's forms:

Proposal (outdated)	This PR (current)
urn:ai:…	urn:air:{publisher}:{namespace}:{name} (ADR-0015)
application/mcp-server+json	application/mcp-server-card+json
minVersion (lower bound only)	versionConstraint (SemVer range matcher)
identityType	credentialPropagation — identityType already means an identifier scheme hint (did/dns/spiffe) on Publisher/Trust Manifest; reusing it would collide

Design notes

• AND vs OR on separate axes. required[] is an AND (every element must
  resolve); an anyOf Dependency Group (two or more alternatives) is an
  OR (any one satisfies the slot). This is the ambiguity ADR-0002 flagged, now
  resolved structurally, and kept distinct from the dual-protocol nested-catalog
  pattern.
• Discovery metadata, not a resolver. A dependency is a reference to
  another artifact's identifier, never an embedded copy. The extension
  declares edges; it does not fetch, install, or version-resolve. Consumers
  MUST NOT auto-fetch or invoke a resolved dependency without applying the same
  trust verification they would apply to any artifact.
• credentialPropagation is advisory only (obo / agent / user /
  none). It lets a planner reason upfront about which credentials it must
  hold; it MUST NOT be treated as a security control. The depended-on artifact
  enforces its real requirements at connection time.

Interoperability impact

No change to interoperability expectations for existing catalogs. The core
schema, CDDL for core types, conformance levels, and specVersion are all
unchanged; a consumer that does not implement the extension ignores it without
error, exactly as for any unrecognized extensions key.

Non-goals

• A dependency resolver / installer or version-resolution algorithm — this
  is discovery metadata only.
• Promoting dependencies to a core field — deliberately kept an extension
  per ADR-0002 / ADR-0021.
• A standalone JSON Schema artifact — the repo's normative schema is CDDL,
  and the extension ships a CDDL block to match. Introducing JSON Schema would
  be a repo-wide decision, not a one-off for this extension.

Validation

• uv run --locked python tools/build_spec.py specification/ai-catalog.md dist/index.html --config specification/respec-config.json — passes.
• uv run --python 3.12 --locked --group docs mkdocs build --strict — passes, no broken links.
• All dependency-bearing JSON examples validated.