Task: Use one rail and one splash header on every setup screen

Every screen that sets something up draws the same chrome. The rail comes from JourneyPage and the splash header from JourneyHeader, and the setup journeys, the registration door and the sign-in dialog all use them unchanged. The setup screen already leads with the project's artwork; the sign-in dialog does not, and the registration door the Entry story adds must. A screen that draws its own rail, or its own banner, is the defect this task exists to prevent.

• The registration door renders on JourneyPage's rail, unchanged: the same entry classes, the same three states, the same circled mark with a tick behind the person, and the same footer.
• The splash is the header JourneyPage is given, and it stands on every step rather than only the first.
• The splash keeps its own 964:323 ratio: the element states its width and height, and nothing crops it or states a height that is not the ratio's, because that is what cut the top and the foot off the wordmark before.
• The sign-in dialog carries the same banner element above its form.
• The banner does not crowd the party picker, the forced password change panel, or the refusal notices: it stands above the work, and the work still reads.
• A test asserts both the rail and the banner render on the screens that carry them, so a future layout change cannot drop either silently.

1. Decide where the banner belongs. The setup screen draws it per screen; a shell that draws it for every visitor is the smaller change and the one that makes "every dialog" true by construction, so try the shell first and fall back to the page if the shell cannot tell a door from a form.
2. Put it on the sign-in dialog, above the credentials form and above the party picker, because the picker replaces the form rather than following it.
3. Put it on the registration door's rail, above the step, so it stays put while the step changes.
4. Assert it in the shell's or the page's test, whichever ends up owning it.

• The artwork is heroSplash in projects/ores.web/packages/web/src/assets/brand.ts, which the site publishes at /OreStudio/projects/ores.web/packages/web/src/assets/ore-studio-splash.png; the prototype uses that URL so what a reviewer sees is the real banner and not a drawing of one.
• The rule the setup screen follows, and this task carries: the image states width 964 and height 323, the class is h-auto w-full rounded-md border border-line, and no height is declared anywhere. JourneyHeader renders it as the step header, which JourneyPage wraps in mb-5 border-b border-line pb-5.
• PublicShell already draws the header mark and the application name for a visitor. The splash is the larger artwork above the work, so it is a second element rather than a replacement for the header.
• The prototype needed both corrections and both are now in it. It drew a rail of its own, and it cropped the splash with max-height and object-fit: cover — the exact failure the setup screen's comment records. The prototype now borrows the application's tokens from styles.css as well, because a prototype in a palette of its own answers the wrong question.
• Where the banner lives, decided. The shell was tried first, as the plan said, and rejected: PublicShell serves both the setup journeys and the door, and the journeys draw the splash inside their own panel above the step. A shell-level copy would double it on every setup screen, so the shell cannot tell a door from a journey. The page owns it instead, and JourneySplash is the single element each page renders: JourneyHeader for the setup journeys, the sign-in dialog above its work, and the door for both its rail header and its closed, failed and loading states.

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 banner is one element and the registration door exists.

• One element. JourneySplash renders the artwork once, at 964:323, and JourneyHeader, the sign-in dialog and the door all render it. The shell was tried first and rejected: it serves the setup journeys as well as the door, and the journeys draw the splash inside their own panel, so a shell-level copy would double it. A test asserts the rendered element states both dimensions and carries no cropping class.
• The sign-in dialog. It carries the banner above its work, and the work — the credentials form or the party picker — stays below it, because the picker replaces the form rather than following it.
• The door. SignUpJourney reads iam.v1.auth.registration-policy and the password policy before it offers anything, and the answer decides which screen a person gets: the closed notice, which names the closure, or the same rail the setup journeys use. The branch is one function, doorState, so it is stated once. The write is deferred to a review step that reads back the tenant, the party and the role, and the confirmation states which of the two accounts was produced.
• The routes. GET /api/registration-policy and POST /api/signup are new, both unauthenticated, both forwarding the bare hostname — the port is not part of a tenant's address — and the second shares the sign-in limiter. A refusal keeps the server's own code, mapped onto the browser's error contract, so the screen branches on a value rather than a sentence.
• Verification. TypeScript: typecheck clean; 291 tests pass across the three packages (web 167, BFF 73, wire protocol 51), of which the new ones are 9 BFF, 8 door, 8 steps, and 3 route-table assertions. Formatting clean. Docs: compass lint clean, all seven doc-lint steps pass, and the site publishes the 28 changed pages with no broken link.
• Live, against the running deployment. POST /api/v1/iam/auth/signup on the environment's HTTP gateway answers {"success":false,"error_code":"signup_disabled"}, which is the defect the survey found, closed: the live path reads the deployment's switch and refuses the registration it should never have accepted. The positive path — an account actually created, in either state — was not driven live, because it would change the environment's settings and leave an account behind.
• The documents are corrected with it. Sign up's coverage table now names the policy read and the refusal code, and four of its seven gaps have closed. What remains is the release of a waiting account, the approval workflow, and a notice that somebody is waiting.