Task: Take the registration defaults into the setup journeys

The Setup journeys carry the registration defaults. First run states whether the installation accepts self-registration and confirms the first tenant as the tenant a registration lands in, and its first sign-in lets the tenant administrator nominate the party a new account joins and the role it receives. New tenant and New party ask the same questions when they create a tenant or a party later. The target state records where the defaults come from and corrects the switch's scope.

• First run carries a registration step, and it is clear which actor sets each value.
• Its first sign-in nominates the party and the role, and says that neither is required.
• New tenant and New party offer the same nomination when they create the tenant or the party.
• The target state records that the setup journeys own the defaults, and says why the sign-up screen cannot.
• The switch's scope is stated: the deployment's answer, read at system scope, seeded false.

1. Add the registration step to First run, after provisioning and before the hand-off, because that is where the tenant exists and the system administrator is still the actor.
2. Put the two nominations on the first sign-in, which is where the tenant administrator already is and where the party choice is made.
3. Add the operations the step needs to the journey's coverage table, marked by whether the subject exists.
4. Record the same questions on New tenant and New party, which create the two things a default points at.
5. Add the section to the target state, and correct the switch's scope while there.

• The correction came from the product owner while the registration door was being prototyped: the person who opens the door is not the person who decides what it opens onto.
• system.user_signups is seeded on the system tenant and its registered default is false, so it is the deployment's answer and a deployment nobody has asked refuses registration. The journey documents previously read it as a per-tenant setting; the target state now states the scope and leaves a tenant override as a later change.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

First run carries a registration step (step 7, with the rail now nine steps), its first sign-in nominates the default party and role, and New tenant and New party offer the same nomination when they create their tenant or party. The step's five operations are in the coverage table, four of them marked missing because nothing writes the switch or reports the policy today.

Registration and Onboarding Defaults gains Where the defaults come from and records the switch's scope. The screen work is not in this task: the setup story owns the setup screens, and this task hands it the requirement.