[SaladDay]

Adding a public Harness currently requires repeating its accepted name in API validation, Core registration, client code and schema annotations. A single authored catalog now binds each identifier to its configuration declaration and Core profile; generated registrations, client names and OpenAPI enums consume that catalog.

Runtime installation discovery and Core qualification remain separate. Native implementations stay in their adapters. The onboarding guide now describes one catalog entry instead of multiple handwritten allowlists. Configuration and selection guides link to the owning lifecycle, model and node contracts, removing duplicated rules and stale node-version guidance.

Validation:

• Focused public API, Harness configuration/profile and CLI tests passed.
• Client tests: 755 passed; client and Web typechecks passed.
• Catalog generation/extension tests and checked-in OpenAPI enum checks passed.
• GitHub full make check, official-client acceptance and Linux/macOS/Windows native checks passed.
• Fresh independent review completed; the generated OpenAPI documentation finding was fixed and document consistency/link checks passed.
• Remote browser acceptance: 84/86 initially passed; both ERR_NETWORK_CHANGED failures passed on targeted rerun.