fix(onboarding): stop the setup flow asking for units the account already holds

The spec's sixth question is skipped when the account already carries the
preferences, and the flow had no way to know: `User.unitPreference` is
nullable with null meaning "default metric", and the account payload coerces
that away, so nothing downstream could tell a chosen metric from an unset
column. The two columns are read raw on the server now, into the same
vocabulary the wire publishes, and a record whose account holds both reads its
`units` step as done — the question answers itself and is never put again.

Read-side only: the stored ledger keeps saying pending, because the person
really has not answered it, and an answer given later still lands.

The two writes the units answer makes — the display columns and the record of
the answer — go in one transaction, so a failure between them can no longer
leave the columns changed with no record of what changed them.

docs/api/openapi.yaml

@@ -63210,8 +63210,14 @@ components:
         - id
         - status
       additionalProperties: false
-      description: One step of the setup flow. The ids are stable; a client that meets one it does not know SKIPS it rather
-        than refusing the list, so the flow may grow a screen without a client release.
+      description: >-
+        One step of the setup flow. The ids are stable; a client that meets one it does not know SKIPS it rather than
+        refusing the list, so the flow may grow a screen without a client release.
+
+
+        `units` carries one resolution the others do not: a record whose account already holds BOTH unit preferences
+        reads as `done` whether or not the question was ever put, which is what stops the flow re-asking a value the
+        account holds.
     OnboardingNeeds:
       type: object
       properties: