Design discussion: namespace-level JSON Schema storage and enforcement (scope, lifecycle, rollout)

Split out from #5659 / #5660 per [this discussion](https://github.com/apolloconfig/apollo/issues/5659#issuecomment-5311734408).

#5660 originally implemented both (1) strict JSON/YAML well-formedness validation and (2) namespace-level JSON Schema storage/enforcement. (1) has been kept as a smaller, focused PR (#5660). (2) is parked here until the design questions below are settled.

## Background

A `json`/`yml`/`yaml` `AppNamespace` would carry an optional JSON Schema document that its content is validated against on every save. The schema was stored once per namespace name on `AppNamespace`, shared by every cluster/env that namespace exists in - the same granularity `format` already uses.

## Open questions

- **Scope and lifecycle**: should a schema be global (one per `AppNamespace`, as originally implemented), environment-specific, cluster-specific, inherited with overrides, or versioned with releases? DEV/staging/production/gray clusters may run different application versions and configuration structures during a rollout - does a single shared schema accommodate that, and if so, on what convention (e.g. expand-contract: additive changes are always safe, narrowing changes only land once every environment can already satisfy them)?
- **Rollout and rollback**: what happens when a schema is tightened and existing saved content in some environment would no longer validate? Does the update itself get checked against currently-saved content across environments, or is that left to the schema author's discipline?
- **Existing-content behavior**: does setting/changing a schema retroactively (re-)validate content that's already saved, or only content saved from that point on?
- **Permissions**: who can view/edit a namespace's schema, and is that the same permission as editing the namespace's content, or a separate one?
- **Public-namespace identity**: for a public namespace linked into many apps, is the schema still a single shared contract, or does it need per-linking-app handling?
- **Expected adoption**: how many namespaces/teams would actually use this, and does it justify the added maintenance surface (DB migration, new APIs, cross-environment propagation, permissions, UI)?

## Prior context

Earlier discussion also covered whether "just don't ever make a breaking schema change" (an expand-contract convention, similar to Avro/Protobuf/Confluent Schema Registry compatibility modes) is sufficient in place of per-env/versioned schemas - see the linked discussion for the full back-and-forth.