refactor: one member order for the 3 wizard containers (RD-38)

RD-22 and RD-23 brought the wizard containers under the 250-line budget, so
`max-lines` reports nothing. The files still read badly. Line count was never
the problem.

Fix three things in all three containers:

1. The member order was scrambled, and it differed per file. `registratie`
   declared `draftSync` in the middle of a run of `computed`s; `herregistratie`
   read `this.stepLabels.length` seven lines before `stepLabels` existed; the
   three files put the copy arrays in three different places. All three now use
   one nine-section order, so they compare side by side.
2. Pure logic sat in the container. Extract `digitalDocumentIds` into
   `upload.machine.ts` — the "digital and finished uploading" filter was
   written out four times, and it removes a `documentId!` assertion from both
   containers. Extract `diplomaMsg` into a sibling of the step files.
3. Comments carried archaeology. Drop the three RD-05 references and keep the
   rule. Drop "replaces sessionStorage" and the note about focus management that
   moved to the shell. Fix `intake`'s class comment, which claimed answers
   persist to sessionStorage and was contradicted 30 lines below.

`phase` deliberately stays in all three: it cannot live in `domain/`, and three
siblings plus three specs is a worse trade than 17 readable lines. The store ⇄
`draftSync` cycle also stays — both callbacks are deferred, so it is safe, and
one comment now names it.

No behaviour change. Member lists and every `private`/`protected`/`readonly`
modifier are unchanged, which the showcase depends on.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

apps/ssp/src/app/registratie/ui/registratie-wizard/diploma-msg.ts

@@ -0,0 +1,28 @@
+import { DuoLookupDto } from '@registratie/contracts/duo-diplomas.dto';
+import { RegistratieMsg } from '@registratie/domain/registratie-wizard.machine';
+import { HANDMATIG } from './beroep.step';
+
+/**
+ * Resolve the diploma that the user picked into the machine message it implies.
+ *
+ * The DUO payload maps a diploma id onto a server-derived beroep and the policy
+ * questions that apply to it. Reading that map is message construction, so it
+ * belongs beside the container, not in the beroep step. The backend stays the
+ * authority on both values (ADR-0001) — this function only selects them.
+ *
+ * Returns null when the id matches no known diploma. The caller then dispatches
+ * nothing and the wizard keeps its current state.
+ */
+export function diplomaMsg(data: DuoLookupDto, id: string): RegistratieMsg | null {
+  if (id === HANDMATIG) {
+    return { tag: 'KiesHandmatig', vraagIds: data.handmatig.policyQuestions.map((q) => q.id) };
+  }
+  const diploma = data.diplomas.find((d) => d.id === id);
+  if (!diploma) return null;
+  return {
+    tag: 'KiesDiploma',
+    diplomaId: diploma.id,
+    beroep: diploma.beroep,
+    vraagIds: diploma.policyQuestions.map((q) => q.id),
+  };
+}