feat(workspace): rework form-origin question into two-question flow (FRM-2572)

[ruchelp]

Problem

When admins create a form, they're asked "How is this being filled in today?" and pick from a single checkbox list that conflates two different questions: whether the underlying process is new or already exists, and (if it exists) what medium currently collects it. Because "This is a new process" sits in that list next to options like "Paper form" and "Emails", admins conflate "new to me digitally" with "genuinely new" — someone digitizing a paper form often picks "new process" simply because the digital form is new, even though the underlying data collection has existed for years. This produces form-origin data that doesn't reflect reality, undermining Ops' ability to tell forms that digitize an existing process apart from forms that collect genuinely new data.

Solution

Splits the single question into two, shown on the same screen. A topic sentence ("Tell us about your process") now sits in the header where the question used to be; Q1 asks whether this is a new or existing process (a plain "New"/"Existing" radio); Q2 — shown only when Q1 = "Existing" — asks how the data is collected today, with a new "Another FormSG form" option added alongside the existing mediums (paper, email, documents, spreadsheets, other form builders, other). Toggling Q1 away from "Existing" and back preserves whatever was ticked in Q2, and the same holds across navigating back to the title screen and forward again.

Storage is unchanged — everything still lands in metadata.formOrigins in the same shape it always has (one new enum member, picked up automatically by the existing backend validator), so there's no migration and no downstream consumer changes. This ships behind the existing paper-tracking flag only; there's no new flag and no gradual rollout — whoever already reaches this screen sees the two-question version as soon as this deploys (see docs/adr/0001-no-variant-logging-for-form-origin-v2.md for why no per-form variant is logged, and what that means for forms created right at the deploy boundary).

Alternatives considered

• We considered defining Q1's answer type (FormOriginProcessAnswer) directly in the payload-builder util where it's first used, but moved it into the wizard context instead, since it's really wizard state, not something the payload builder itself owns.
• We considered running a full visual regression pass against a design reference before opening this PR, but neither Figma nor a browser-automation tool was available while implementing this, so verification leaned on the RTL test suite and a shared mockup instead. The Storybook states are still updated with the new variants, so Chromatic picks up real regression coverage in CI from here.

Breaking Changes

No - backwards compatible. metadata.formOrigins keeps the same { value, othersInput } shape; the new FormOrigin enum member is additive and validated automatically by the existing Joi schema.

Tests

TC1: Visual check on the create-form flow

• Start a new form, reach the origin screen
• Confirm "Tell us about your process" appears as the screen header, with Q1 ("New" / "Existing") shown as radio buttons beneath it
• Select "Existing" and confirm Q2 appears with all medium options, including "Another FormSG form" shown distinctly from "Other form builders"
• Select "Other" and confirm the free-text field appears with its character counter

TC2: Selection-preserving behavior

• On the origin screen, select "Existing" and tick a couple of mediums
• Switch to "New", then back to "Existing" — confirm the same mediums are still ticked
• Go back to the title screen, then forward again to the origin screen — confirm the selections are still there

TC3: Duplicate and use-template parity

• Duplicate an existing form and confirm the same two-question screen appears, for both a "new process" and an "existing process" answer
• Create a form from a template and confirm the same two-question screen appears, for both answers

[ruchelp]

This Controller for Q2 (formOrigins.value) stays mounted at all times — only the markup it renders is conditional on formOriginProcess === 'existing' (see the ternary in the render prop below). This is deliberate: it's what makes Q2's ticks survive toggling Q1 away and back (and navigating back to the title screen and forward again) without any extra state — react-hook-form never unregisters a field it hasn't unmounted. The rules.validate closure below reads formOriginProcess to skip the "at least 1" check whenever Q1 isn't "existing", rather than conditionally registering the field itself.

[linear-code]

FRM-2572