#2478 Namespace names are not reserved against cache/datastore layout directories (e.g. data)

Problem

Namespace slugs are validated only by pattern and length (src/domain/data/namespace.ts: ^[a-z0-9]([a-z0-9-]*[a-z0-9])?$, max 64). Nothing reserves names that also appear as top-level segments in the cache and datastore layout. So data (and likely other layout directory names) is a legal namespace even though it makes paths ambiguous.

A namespace's cache subtree is <cachePath>/<ns>/... and its remote keys are <ns>/..., using the same inner layout as solo mode, whose top-level directories include data/. With ns = data:

• Solo-layout leftovers at <cachePath>/data/... and the namespace directory <cachePath>/data/ are the same directory.
• Root-level (pre-namespace) remote keys data/<type>/... sit under the namespace prefix data/, which is what the S3/GCS extensions' solo-to-namespace data-key migration and foreign-namespace detection key off.
• Any prefix-based rule of the form "strip or skip a leading <ns>/" cannot tell data/<type>/... (real) from data/data/<type>/... (doubled). This came up while designing the cleanup for swamp-club#2404, where the stray-path filter has to special-case ns === "data".

I have not reproduced a live failure with ns = data; the above is from reading the layout code. Worth confirming which names actually collide before choosing the reserved list.

Suggested direction

• Define the set of names reserved by the cache/datastore layout (at least the top-level solo-layout directories such as data) and reject them in createNamespace.
• Decide how to handle repos already bound to a reserved name: a migration to a new namespace, or a clear error with a documented rename path.
• Consider whether datastore extensions should share one exported list rather than each hard-coding assumptions.

Related

• swamp-club#2404