calm-hub: design namespace-addressable controls, or confirm they shouldn't exist

Should `/calm/namespaces/{ns}/controls/{name}` exist? PR #3066 originally wired `CONTROL` into the namespace-scoped front controller, then reverted it on review — controls are domain-scoped everywhere else (`ControlResource` is `@Path("/api/calm/domains")`; every `ControlStore` method takes `domain`, not `namespace`).

**Why the original wiring broke:**
- GitHub mode returned **HTTP 500**, not 404 — `DomainNotFoundException` wasn't in the front controller's catch list. No test exercised the route; hidden by fixtures that used the same string for namespace and domain
- Mongo/nitrite can't represent it — `createMapping` requires a namespace, but a control is keyed by `(domain, controlId)`, no namespace

**If we want to support it,** it needs: domain-keyed `resource_mappings` rows, relaxed `requireNamespace` checks in both mapping stores, a `SchemaMigrationStep` in each backend plus `init-mongo.js`, a `LATEST_SCHEMA_VERSION` bump, and a backfill. A deliberate design decision, not a mechanical fix.

Start with PR #3066, the namespace-scoped front controller, ControlResource, and the ControlStore methods. Compare the Mongo and nitrite mapping stores, their SchemaMigrationStep implementations, and init-mongo.js to determine whether namespace-addressable controls are coherent. Done means a documented design decision, with the required migration and backfill scope identified if the route is supported.

Written by the indexing model from the issue text.