A Process may be named for another Process's backup identity, and then is it #242

What

A backup identity is named <process>-backup (CONTEXT.md, Backup Identity), and nothing refuses a Process of that name in the same project file. postgres, backed up, and another Process called postgres-backup then share one name for everything a name identifies:

• one ServiceAccount, so the Process runs as the backup identity and holds the off-cluster destination's credential;
• one Vault role and policy, <namespace>-postgres-backup, written twice at one path (this one is refused today, as E_PATH_COLLISION, but only where both hold a grant);
• one instance label, so the policy that admits the backup identity to the datastore's dump surface admits that Process too, and the backup identity's own policy selects its pods.

E_DUPLICATE_PROCESS_NAME checks Process names against each other, not against the identities the model derives from them. The migration identity, <application>-migration, has the same shape.

What to decide

Whether a Process may carry the name of a derived identity. The straightforward rule is that it may not: within a project file, no Process is named for another Process's backup identity or an Application's migration identity, refused at composition with its own code or under E_DUPLICATE_PROCESS_NAME.

Acceptance criteria

• Chapter 40's completeness table states the rule and its code.
• Both implementations refuse a project file with a Process named <other>-backup beside a backed-up <other>, with a refusal fixture.

Found while rendering the backup identity's network policy (#199). Part of #195.