[paullatzelsperger]

The TSP's onboarding spec (dx-onboarding-api/dataspace-api-docs.yaml) renames the status ON_HOLD to CHANGES_REQUESTED and adds a changeRequest to the onboarding request. This PR makes the VE's TSP stand-in serve that flow, and makes the Membership Hub answer it.

Every onboarding request is asked for changes once

This is a deliberate behaviour change. The VE has no TSP operator, so nothing would ever request changes and the new code path would never run. To cover it, the automatic review now sends every request through one change-request round before it approves:

SUBMITTED → UNDER_REVIEW → CHANGES_REQUESTED → (applicant submits again) → UNDER_REVIEW → APPROVAL_IN_PROGRESS → APPROVED

• The changeRequest it hands back is canned: a comment saying that nothing needs correcting and that submitting again is enough, with an empty items list.
• Each request takes the detour exactly once. After the resubmit it is approved as before.
• It can be switched off per kind of participant with dx-onboarding.review.request-changes.hosted and .external (both true by default, in application.yaml and in charts/dx-onboarding-api/values.yaml). With both off, a request goes SUBMITTED → UNDER_REVIEW → approval.
• It only applies to requests that are reviewed automatically (auto-approve). A request that waits for an operator stays in SUBMITTED.

Consequences:

• The Membership Hub resubmits by itself, for hosted members and for the external systems under test it registers. A participant that calls the onboarding API on its own must resubmit itself, or it stays in CHANGES_REQUESTED.
• Every onboarding takes one extra hub registration poll (participant.registration.poll-interval, 15s by default).

dx-onboarding-api

• OnboardingStatus: ON_HOLD becomes CHANGES_REQUESTED. It still holds its DID and counts toward the pending-request quota.
• New ChangeRequest record (requestedAt, comment, items[{field, documentType, note}], resubmittedAt), carried on OnboardingRequest and returned as changeRequest.
• While CHANGES_REQUESTED, the applicant can replace the data and add, replace or remove documents, as on a draft. Deleting the request stays draft-only.
• POST /{requestId}/submit on a CHANGES_REQUESTED request runs the same checks as the first submit (completeness, DID free and resolvable), skips the pending quota, moves it to UNDER_REVIEW and sets changeRequest.resubmittedAt. submittedAt keeps the time of the first submit, and no second onboarding.started event is published.
• A submit that carries the Idempotency-Key of the first submit together with an outdated version is treated as that first submit sent again, not as the resubmit. Otherwise a retried first submit would get a 409 once the review has already asked for changes.
• AutomaticReview now takes a request on (UNDER_REVIEW) before it decides, and ApprovalService approves from SUBMITTED or UNDER_REVIEW.
• The title of invalid-onboarding-request-state changes from "Request no longer a draft" to "Request cannot be changed".

membership-hub

• DecadeXOnboarding.pollStatus: on CHANGES_REQUESTED it submits the request again unchanged, under the version from the ETag and the same dx-submit-<externalId> key, and reports PENDING. A refused resubmit fails that poll and is retried on the next one.

Tests and docs

• New unit tests for each transition in both modules. SpecConformanceTest now also checks the status enum and the change-request schema against the yaml, so a rename in the spec fails the build.
• Both unit test suites pass locally (dx-onboarding-api 100 tests, membership-hub 102). The full e2e run has not been done on this branch.
• dx-onboarding-api/README.md and onboarding.md describe the flow, including the state diagram; membership-hub/README.md mentions the resubmit.

Not in this PR

• The prose in dataspace-api-docs.yaml still says a submitted request can no longer be changed. That text belongs to the spec's owner.

🤖 Generated with Claude Code