fix(infra): deploy BPMN + DMN as one .bar so the inline decision resolves (S-13, refs #14)

The DMN service task resolves its decision scoped to the process's own deployment,
so a standalone .dmn deployment was invisible (FlowableObjectNotFoundException: No
decision found for key: diploma-eligibility). Bundle registratie.bpmn +
diploma-eligibility.dmn into a single registratie.bar and deploy it as one
deployment, giving the decision the process's parent deployment id. flowable-rest
does not expose the dmn-api app, so co-deployment is the way in.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/architecture/adr-0016-diploma-eligibility-dmn.md

@@ -36,9 +36,12 @@ only new job is to carry the diploma origin and pass it into the process as a st
   `DiplomaOrigin` (Binnenlands/Buitenlands); `SubmitRegistration` passes it to
   `StartRegistrationProcessAsync`, which sets it as the `diplomaOrigin` start variable. The domain
   never evaluates the DMN and never learns the route — that is the process's concern.
-- **Deployed like the BPMN.** The DMN is version-controlled in `workflows/` and deployed to the DMN
-  engine by the same `flowable-init` step (via `dmn-api/dmn-repository/deployments`), staged into the
-  `fl-bpmn` volume alongside the BPMN.
+- **Deployed in one `.bar` with the BPMN.** The DMN is version-controlled in `workflows/` and bundled
+  with `registratie.bpmn` into a single `registratie.bar` (by `seed-config.sh`) that `flowable-init`
+  deploys as one deployment. This is required, not cosmetic: `flowable-rest` does not expose the
+  `dmn-api` app, and Flowable resolves an inline DMN scoped to the process's own deployment — so a
+  standalone `.dmn` deployment is invisible to the process (`FlowableObjectNotFoundException: No
+  decision found for key`). Co-deploying gives the decision the process's parent deployment id.
 
 ## Consequences