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>

libs/shared/docs/behaviour-spec.mdx

@@ -20,7 +20,7 @@ tested where._
 
 Every bullet below is a real test name from the suite — an `it()` title (frontend) or a test
 method name (backend), read as a sentence. Nothing here is hand-written prose: this page
-**is** the suite, reshaped for a business reader. 556 frontend behaviours across
+**is** the suite, reshaped for a business reader. 562 frontend behaviours across
 9 contexts; 261 backend behaviours across 42 test
 classes.
 
@@ -545,6 +545,12 @@ classes.
 - lists soort/waarvoor/status/referentie/ingediend, plus reason when rejected
 - reference falls back to em dash for a Concept
 
+#### diplomaMsg
+
+- resolves a known diploma into KiesDiploma with the server-derived beroep
+- resolves the manual sentinel into KiesHandmatig with the maximal question set
+- returns null for an unknown diploma id
+
 #### findConcept
 
 - returns the id of the existing Concept of the given type
@@ -857,6 +863,12 @@ classes.
 - emits documentId for completed digital uploads and channel for post
 - omits digital categories with no completed upload
 
+#### digitalDocumentIds
+
+- returns the id of a completed digital upload
+- omits an upload that is still in flight
+- omits a category that the user delivers by post
+
 #### flushPendingGuard
 
 - flushes then allows navigation when a write is pending

libs/shared/src/domain/upload.machine.spec.ts

@@ -8,6 +8,7 @@ import {
   categorySatisfied,
   requiredCategoriesSatisfied,
   deliveryRefs,
+  digitalDocumentIds,
   inFlight,
   rejectReason,
   planFileSelection,
@@ -284,6 +285,28 @@ describe('deliveryRefs', () => {
   });
 });
 
+describe('digitalDocumentIds', () => {
+  it('returns the id of a completed digital upload', () => {
+    let s = select(stateWith([cat({ categoryId: 'a' })]), 'a', 'u1');
+    s = reduceUpload(s, { type: 'UploadComplete', localId: 'u1', documentId: 'doc1' });
+    expect(digitalDocumentIds(s)).toEqual(['doc1']);
+  });
+
+  it('omits an upload that is still in flight', () => {
+    const s = select(stateWith([cat({ categoryId: 'a' })]), 'a', 'u1'); // still queued
+    expect(digitalDocumentIds(s)).toEqual([]);
+  });
+
+  it('omits a category that the user delivers by post', () => {
+    let s = stateWith([cat({ categoryId: 'a' }), cat({ categoryId: 'b' })], {
+      deliveryChannel: { b: 'post' },
+    });
+    s = select(s, 'a', 'u1');
+    s = reduceUpload(s, { type: 'UploadComplete', localId: 'u1', documentId: 'doc1' });
+    expect(digitalDocumentIds(s)).toEqual(['doc1']);
+  });
+});
+
 describe('rejectReason', () => {
   it('rejects a disallowed type', () => {
     expect(

libs/shared/src/domain/upload.machine.ts

@@ -312,6 +312,14 @@ export function deliveryRefs(
   return refs;
 }
 
+/** Ids of the documents that the user delivers digitally and that finished uploading.
+    A category set to post, or one whose upload is still in flight, contributes nothing. */
+export function digitalDocumentIds(s: UploadState): string[] {
+  return deliveryRefs(s)
+    .filter((r) => r.channel === 'digital' && r.documentId)
+    .map((r) => r.documentId as string);
+}
+
 /** Used by the shell to find what to poll on return: still-in-flight uploads. */
 export const inFlight = (s: UploadState): Upload[] =>
   s.uploads.filter((u) => u.status.type === 'queued' || u.status.type === 'uploading');