#4130 Check registry listing limits in extension quality/push and suggest splitting into per-domain extensions

Problem

The registry silently discards an extension's whole listing when contentMetadata exceeds a limit (50 models per extension, 50 methods per model, 30 arguments per method, 30 global arguments per model). The author only learns about it from an easy-to-miss warnings.registry line after the push, or by noticing a blank extension page (see the companion bug about the blank page).

This bites large API wrappers in particular. Generating one model per resource for a broad SaaS API (Ashby: 57 resources, 201 endpoints) passes every local check: extension fmt, extension quality (87%, provisionally 100%) and push --dry-run. It then publishes with an empty page.

Proposal

Add a listing-limits check to swamp extension quality and the push pre-flight (and so to --dry-run), using the same limits the registry enforces:

• Run the CLI content extractor and the same validation the registry runs, before archiving.
• On a breach, block the push (or require --yes) with a message that names the limit, the count, and the offending manifest, model or method, e.g. contentMetadata.models: 57 exceeds the registry limit of 50 — the extension page would be blank.
• Include a remediation that points at the established pattern: split into several extensions by domain, one manifest each, named @collective/<vendor>/<domain>. This is how @swamp/vercel/* and @swamp/aws/* are organised, and how @keeb/ashby was fixed (@keeb/ashby/candidates, /jobs, /interviews, /offers, /sourcing, /surveys, /organization).
• Also warn when the extractor finds a model whose methods or global arguments it can't read (spread methods, imported globalArguments schema). Those quietly publish as "no methods" or "no arguments" too.

Alternatives

• Document the limits only. That helps, but the check is cheap and the failure is silent, so docs alone will keep being missed (see the companion skill/docs request).
• Raise the limits. That doesn't remove the cliff, and one-extension-per-domain is a better package shape for large APIs anyway: smaller installs and clearer pages.