Measure the facts G22c's decision rests on

Measure the facts G22c's decision rests on G22c says to pick one of three URL shapes before writing code. Its costs were stated as prose about "the visitor surface" as a whole, and the schema says those two URLs are not alike. share_links.token is 256 bits from the OS CSPRNG. portals.key is a human-chosen slug, `^[a-z0-9][a-z0-9-]{1,62}$`, commented in its migration as "the URL name, when public". So /s/{token} has no collision problem to solve: two tenants minting the same 256-bit token does not happen, a global token-to-tenant lookup costs nothing in collisions, and no published URL changes. The trilemma is entirely about /p/{key}, where two customers will both want `spring-2026` and where every one of the three costs — collision, URL migration, length — actually lands. That means the choice can be made for portals alone and shares resolved globally today, rather than treating this as one uniform change. Also recorded what a global registry costs either way, since the entry did not: a row in dam_global written on creation, which is a cross-schema write, and a second place a share exists — so a share deleted in a tenant schema without its global row removed leaves a token resolving to a tenant that then finds nothing. Reconciliation, not a constraint, because the two live in different schemas. The entry's own numbers were checked rather than assumed: the eighteen .pool() reads are still exactly eighteen. They are in shares.rs, portals.rs and downloads.rs, not delivery.rs — I looked in the wrong file first and the count came back zero. Evidence only. The decision is still open, and a single-tenant deployment remains correct in the meantime.