Task: Create the first administrator from the setup screen

The setup screen reports the state and cannot change it. Give it the one action that does: create the first administrator, which is the write that closes bootstrap mode and opens the sign-in screen.

• The setup screen creates the first administrator with no session, through a hand-written BFF route and a wire-protocol client method, parsing the generated schema.
• The password field shows the rules the server enforces, and the form refuses to submit until they are met.
• The server closes bootstrap mode when the administrator is created, and the screen asks the gate again rather than deciding the new state itself.
• The route refuses when the installation is not in bootstrap mode, because the function behind the subject grants SuperAdmin and does not check the flag itself.
• The path is proven against the running fleet: create, the flag flipping, a second create refused, and a sign-in with the created account.
• The workspace typechecks, passes the format check, tests green, and builds.

One commit, because it is one action end to end.

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

The live path, against this environment's running fleet, before the environment was reset:

• The route's guard is the only one. ores_iam_create_initial_admin_fn does not check bootstrap mode and does not refuse a second administrator under a different username; the unique index on (tenant_id, username) refuses only a repeat of the same name. Filed as a capture, because the fix belongs in the function, where the privilege is granted.
• The reply carries no tenant name. The C++ response struct declares tenant_name and the handler leaves it empty, so the HTTP shape returns the account and the tenant id and does not promise a name. A field the server never fills is worse than an absent one: the browser would render a blank.
• The environment was reset, not left provisioned. Creating the administrator closes bootstrap mode, so testing it changes what the next person sees. The reset returns the system to bootstrap mode with the account soft-deleted, which is why the setup screen is the live state again rather than the sign-in page.

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.

The setup screen creates the first administrator, so the write that closes bootstrap mode is the one action the screen carries.

The call is the generated subject with hand-written schemas; the route is unauthenticated because the deployment has no account to present; and the route refuses once the deployment says it is no longer in bootstrap mode. That refusal is the only guard on a function that grants SuperAdmin and does not check the flag itself, and the function is filed as a capture because the fix belongs there.

The path was proven against the running fleet rather than only in tests: create, the flag flipping, a second create refused, and a sign-in with the new account. The environment was then reset to bootstrap mode, so the setup screen is what a browser sees here again.

The form's password rules are the rules the server enforces, because the field computes them from the same policy the validator does; the submit waits until they are met; and a failure shows the server's own words rather than a translation of them.