fix(onboarding): derive the module map only from a questionnaire that was finished

The only gate on the derivation was Q1 being set, so one answer was enough to
turn the whole questionnaire into a module map. Two ways that landed wrong and
they compound. Somebody answers who the record is for, closes the tab, and
later finishes the legacy four-step wizard, which posts to this same endpoint
and knows nothing about these questions: the five unanswered ones each read as
their conservative default, eleven surfaces are written off, and the
once-only marker makes it unrepeatable. Or any client patches one answer and
posts the confirm straight back.

The gate now asks whether every question has an answer or a deliberate pass.
A half-answered flow derives nothing, is not stamped complete, and keeps its
confirm step pending, so finishing the questions later still does the work.
The legacy arm is untouched: a caller with no setup row still answers the
fixed acknowledgement it always did.

docs/api/openapi.yaml

@@ -16371,14 +16371,20 @@ paths:
 
 
         v1.39 — this is also the needs-based flow's confirm endpoint, and the two halves live side by side. For a record
-        that answered the questions (Q1 is set), it derives that record's module map from the answers and applies it,
-        ONCE: the derivation marker is what stops a second confirm re-applying the questionnaire over decisions taken in
-        Settings since, and `POST /api/onboarding/restart` clears the marker when the person asks for the questions
-        again. The merge is one-directional — a module the answers name is switched on, a module they do not name is
-        switched off only where the record does not already carry an explicit on. The `cycle` key is not written here at
-        all: it delegates to the cycle profile, which this route sets to `true` when the cycle area was chosen and never
-        to `false`. The response then carries `onboarding` beside `completed`; a caller that never entered the needs
-        flow gets the fixed acknowledgement it always did.
+        that FINISHED the questions — every one of them answered or deliberately passed — it derives that record's
+        module map from the answers and applies it, ONCE: the derivation marker is what stops a second confirm
+        re-applying the questionnaire over decisions taken in Settings since, and `POST /api/onboarding/restart` clears
+        the marker when the person asks for the questions again. The merge is one-directional — a module the answers
+        name is switched on, a module they do not name is switched off only where the record does not already carry an
+        explicit on. The `cycle` key is not written here at all: it delegates to the cycle profile, which this route
+        sets to `true` when the cycle area was chosen and never to `false`. A half-answered flow derives nothing and is
+        not stamped as complete: the answers become a module map, and a flow somebody abandoned after the first screen
+        would have every remaining question read as its conservative default. The same gate is what keeps the LEGACY
+        wizard's completion out of the derivation, since that wizard never puts these questions.
+
+
+        The response then carries `onboarding` beside `completed`; a caller that never entered the needs flow gets the
+        fixed acknowledgement it always did.
 
 
         The older sibling of `POST /api/onboarding/step`. It is unconditional in a way the step route is not: it stamps