A Project's name is unconstrained: it can derive kube-system, or a Vault name with two readings #244

What is wrong

A Project's name is any text (project: text in src/model/project-intent.ts), and its namespace derives as <project>-system. Two things follow that nothing refuses:

• A name that derives a namespace the estate does not own. project: kube derives kube-system, and project: flux derives flux-system, the bootstrap set's own. Every object the project renders, its identities' Vault roles included, lands there.
• A name that holds -system. A Vault name is <namespace>-<identity> (0031). Project data-system-api with identity worker and project data with identity api-system-worker both derive data-system-api-system-worker. E_PATH_COLLISION catches the pair when both exist in one composition; it does not catch one of them alone, read the other way by whatever consumes the name.

Where it showed

The Vault policy job (JorisJonkers-dev/delivery#5) reads a document's name one way, the Project before the first -system-, and refuses a role bound any other way. So a Project whose name holds -system renders documents the job refuses, which stops its Reconcile Unit. That is the job failing closed on a name the model should not have accepted.

What to decide

• The shape a Project's name may have: a DNS label, with no -system in it.
• Which names are reserved because their namespace is not the estate's to derive: kube and flux at least.
• The code a refused name gets, and where it is checked (the schema, or the read-and-check step).

Part of #195.