feat(backend): enforce the scholing threshold server-side (WP-69)

ADR-0001's own canonical "config value" example was unenforced: GET
/intake/policy echoed ScholingThreshold, but no request DTO carried a
scholing answer, so the server had nothing to re-validate. A crafted
POST could skip a requirement the wizard presents as mandatory.

IntakePolicy.RejectIncompleteScholing is the authority — three-valued
completeness (below threshold an answer is required; "nee" is legal and
still submits; punten only belong to a followed scholing), living in the
class that owns the constant so scripts/check-seam.sh keeps guarding the
FE/BE literal pair. Both submit paths call it; a violation 400s with
ProblemDetails and leaves the aanvraag a Concept. Gated on
Type == "intake" (the endpoint's switch lumps herregistratie with
intake, which has no scholing question), and guarded by `reject is null`
so a zero-uren submission is still decided on its merits.

Also fixes a live FE bug in the same rule: validateStep required punten
whenever scholingGevolgd was 'ja' regardless of lageUren, while the
template renders those fields only when lageUren — so answering 'ja'
then raising uren either blocked the user on an invisible field or
emitted aanvullendeScholing: undefined alongside punten. punten now
derives from aanvullendeScholing, so that combination is unrepresentable
in ValidIntake.

Note: EndpointTests' Worked_hours_submission_succeeds was itself
asserting the vulnerable payload ({ uren: 40 }, no answer) and needed a
complete answer added; the zero-hours rows are the ordering regression
net and are unmodified.

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

backend/src/BigRegister.Api/Program.cs

@@ -195,8 +195,16 @@ api.MapPost("/herregistraties", (HerregistratieRequest req, HttpContext ctx) =>
 .ProducesProblem(StatusCodes.Status422UnprocessableEntity);
 
 api.MapPost("/intakes", (IntakeRequest req, HttpContext ctx) =>
-    Submit(ctx, "intake", SubmissionRules.RejectZeroUren(req.Uren)))
+{
+  // WP-69: completeness check outside Submit(...) — deliberately not folded into `reject`,
+  // so this 400 is never cached in IdempotencyStore the way a 422 rejection would be.
+  var reject = SubmissionRules.RejectZeroUren(req.Uren);
+  if (reject is null && IntakePolicy.RejectIncompleteScholing(req.Uren, req.AanvullendeScholing, req.ScholingPunten) is { } incomplete)
+    return Results.Problem(detail: incomplete, statusCode: StatusCodes.Status400BadRequest);
+  return Submit(ctx, "intake", reject);
+})
 .Produces<ReferentieResponse>()
+.ProducesProblem(StatusCodes.Status400BadRequest)
 .ProducesProblem(StatusCodes.Status422UnprocessableEntity);
 
 api.MapPost("/change-requests", (ChangeRequestRequest req, HttpContext ctx) =>
@@ -361,6 +369,14 @@ api.MapPost("/applications/{id}/submit", (string id, SubmitApplicationRequest re
     _ /* herregistratie | intake */ => (SubmissionRules.RejectZeroUren(req.Uren ?? 0), true),
   };
 
+  // WP-69: intake-only (herregistratie has no scholing question) — guarded by `reject is
+  // null` so a { uren: 0 } submission is still decided on merit (RejectZeroUren) and
+  // completeness is moot; placed before the document-ownership check and
+  // ApplicationStore.Submit so a rejected submit leaves the aanvraag a Concept (retryable).
+  if (existing.Type == "intake" && reject is null &&
+      IntakePolicy.RejectIncompleteScholing(req.Uren ?? 0, req.AanvullendeScholing, req.ScholingPunten) is { } incompleteScholing)
+    return Results.Problem(detail: incompleteScholing, statusCode: StatusCodes.Status400BadRequest);
+
   var docs = req.Documents;
   var documentIds = docs?.Where(d => d.Channel == "digital" && d.DocumentId is not null).Select(d => d.DocumentId!).ToList();