Clarify catalog projection terminology

[jonathanhefner]

Summary

• rename Registry Projection to Catalog Projection
• describe projection as creating an entry from a source Catalog Entry in another AI Catalog or a source record in another system
• use catalog operator for the entity applying identifier-selection rules and connect that role to the top-level host field
• scope the ordered selection rules to first incorporation and rely on the existing stability requirement after publication
• label the AIR naming block as the explicit urn:air Identifier Format
• align ADR-0021 with the specification terminology

Motivation

This responds to terminology and lifecycle questions raised during review of Agent-Card/ai-catalog#105.

The previous wording framed projection as registry-specific and embedded a stateful rule that presupposed the catalog could determine whether an arbitrary upstream identifier change still represented the same artifact. The revised wording describes the source and destination objects directly, applies the decision tree only when an entry is first incorporated, and leaves later changes governed by the existing identifier-stability requirement.

Scope

This PR does not introduce an official federation-origin extension. That proposal requires separate semantics for origin claims, trust, and chain traversal.

Review focus

• whether catalog operator accurately names the entity represented by top-level host
• whether the source Catalog Entry versus source-system record distinction is clear
• whether scoping selection to first incorporation removes the unintended artifact-equivalence assumption without weakening identifier stability

Validation

• /Users/jonathanhefner/Projects/ai-catalog/.venv/bin/mkdocs build --strict --site-dir /tmp/ai-catalog-issue-102-catalog-projection-site
• /Users/jonathanhefner/Projects/ai-catalog/.venv/bin/python tools/build_spec.py specification/ai-catalog.md /tmp/ai-catalog-issue-102-catalog-projection-spec.html
• git diff --check