Tenant ids have no canonical validator: divergent charsets and an infallible TenantId::new

[mauripunzueta]

Summary

Tenant ids have no single canonical validator. TenantId::new is infallible and
stores the string verbatim, and upstream there are three divergent charset
checks plus paths with none — so each backend defends individually and
inconsistently, which is how the Elasticsearch case-collision defect (companion
issue) became reachable.

Spun off from #369 / PR #379.

Evidence

• TenantId::new is infallible with no charset constraint —
  crates/persistence/src/tenant/id.rs:61-63.
• Three different upstream validators, none shared:
  • crates/rest/src/tenant/resolver.rs:283 (is_ascii_alphanumeric() …)
  • crates/rest/src/middleware/tenant_prefix.rs:63
  • crates/rest/src/handlers/admin_tenants.rs:98 (also permits . and /)
  • the JWT tenant extractor validates nothing.
• Backends therefore compensate individually: the S3 keyspace added an injective
  escape (crates/persistence/src/backends/s3/keyspace.rs:383) after S3 tenant registry: a tenant named tenants permanently breaks list_tenants() #271, while
  Elasticsearch still collapses case (companion issue).

Proposed direction

Introduce one canonical constructor — e.g. TenantId::parse(&str) -> Result<…>
with a documented charset — and enforce it at tenant creation and at the REST
tenant-routing boundary. Keep an unchecked internal constructor only for trusted
construction (e.g. SYSTEM_TENANT). This lets each backend state a charset
precondition instead of re-deriving one, and closes the class of cross-tenant
collisions rather than one instance of it.

[mauripunzueta]

Carrying forward the one requirement unique to #382 (closed as duplicate of this issue):

The canonical validator must settle the / question explicitly. Today the domain model and the REST layer disagree — admin_tenants.rs:98 permits / in the charset [A-Za-z0-9._/-], while tenant/resolver.rs:283 (is_ascii_alphanumeric()-based) does not. A tenant id containing / has different meaning to a path-prefix router, an S3 keyspace, and an Elasticsearch index name, so TenantId::parse should either reject it outright or define one escaping rule that all three honour. Leaving it unspecified is what produced the divergence in the first place.

Also worth recording from #382: there are ~198 TenantId construction sites across the workspace, and several are not behind the HTTP front door (subscriptions/src/rehydrate.rs, persistence/src/composite/merger.rs, bulk-export/submit paths, admin handlers, config defaults). A validator enforced only at the REST edge would not cover them.

[mauripunzueta]

Draft PR #450 opened against main for this.

Charset settled as [A-Za-z0-9._-] plus /, 1..=64 bytes, case-preserving, with reserved segments checked in every position. TenantId::parse is the canonical constructor; TenantId::new stays unchecked for trusted reconstruction, as this issue proposed.

Two things the issue's evidence understated, both fixed there:

• The header validator failed open — HeaderTenantExtractor filtered an invalid value to None, so TenantResolver::resolve fell through to the default tenant and served the request 200. X-Tenant-ID: acme.corp silently read and wrote the default tenant's data.
• The reserved-name check compared the whole id, so acme/resources passed. On S3 that nests inside the acme/resources/ prefix tenant acme lists — and that purge_tenant_data("acme") deletes.

Case is deliberately not folded: #384/#446 makes the Elasticsearch derivation injective, which removes the reason to narrow the charset, and folding would silently merge mixed-case tenants that every other backend keeps apart. The 64-byte cap is also what #446's index-length proof rests on.