Support nested catalogs (application/ai-catalog+json entries), with depth cap and cycle tracking

An AI Catalog entry can point at another catalog rather than at an artifact: per the specification's Composability goal, "a catalog entry can have a type of application/ai-catalog+json". Hosts can use this to organize by team, product line, or business unit rather than flattening everything into one document at the domain root.

We do not currently account for this. A consumer that fetches a catalog, filters for application/mcp-server-card+json, and stops will silently find nothing on any domain that organizes by nesting — including the shapes the spec itself uses as worked examples.

Resolving nested catalogs is not just "recurse." The spec attaches two requirements:

• Depth limit. "Clients processing nested catalogs SHOULD impose a maximum nesting depth to prevent circular references. A depth limit of 4 is RECOMMENDED. Implementations MAY support deeper nesting but SHOULD document their limit." (See also ADR-0001.)
• Cycle tracking. "Clients SHOULD track the set of catalog URLs visited during recursive resolution and reject any catalog URL that has already been fetched in the current traversal path." This lives in the spec's Security Considerations — unbounded traversal is a denial-of-service vector, not just a correctness bug.

Scope

• SDK reference implementations — recursive resolution with a documented depth cap and a visited-URL set.
• docs/discovery.md — document nested entries in the client discovery flow, and add the depth/cycle requirements to Security Considerations alongside the existing denial-of-service guidance.
• docs/best-practices.md — currently describes a single flat catalog. Update once the above lands.

Relationship to #43

Same shape: both are places where the AI Catalog spec supports something broader than the flat, well-known-path-only model this extension documents and implements today. Worth deciding whether they land together, since both change what "resolve a catalog" means for a consumer.

Not urgent

A single flat catalog at the well-known path is the common case, and nothing is blocked on this. Filing so the gap is tracked rather than rediscovered.

Start with the SDK reference implementations, then read docs/discovery.md and docs/best-practices.md. Trace how a consumer resolves a catalog and update it for nested application/ai-catalog+json entries with the documented depth cap and visited-URL tracking. Done means the discovery and best-practices documentation describe nested catalogs, depth limits, and cycle handling alongside the implementation.