Merging organisations leaves the source supplier's applications and services pointing at the merged-away supplier

[rubenvdlinde]

What goes wrong

When an admin merges one organisation into another, the applications and services the source organisation supplies keep pointing at the source. After a supplier takeover the products stay attached to the merged-away supplier, which is now a tombstone.

Evidence, re-read at c9760e0

• The merge runs from the OrganisationMergePanel on OrganisatieDetail (src/manifest.json:430) through POST /api/organisaties/{uuid}/merge (lib/Controller/MergeController.php:142, admin only) into lib/Service/MergeOrganisatieService.php.
• The relation map FIELD_RELATION_TYPES (:111-115) re-points only usage.consumer and usage.participants, contactPerson.organization, and provider on the connection schema (keyed aanbod). SELF_ORGANISATION_RELATION_TYPES (:122) re-points @self.organisation of catalogContract and compliancy only.
• module.provider and catalogService.provider in lib/Settings/softwarecatalogus_register.json are both $ref: #/components/schemas/organization with semantic type Vendor ("De aanbieder van de applicatie", "De leverende partij die deze dienst beschikbaar stelt"). Neither schema is in either list, and the modules' and services' own @self.organisation is not re-pointed either.
• The source is then tombstoned with status = 'merged' and mergedInto (:11-12, :100).
• The merge dry run counts per relation type from the same lists (:245, :264), so its preview does not show the products that will be left behind.

Context: VNG requirement

This is VNG #141 in issues.md:241-262 (merge after municipal redistricting or a supplier takeover). Its acceptance criterion "All relationships (aanbod, gebruik, koppelingen) from Object A are transferred to Object B" is ticked, but the code does not transfer the supplier's applications and services. Filed here as a defect against that ticked criterion rather than as a new requirement.

Why it matters

After a takeover, the acquiring supplier does not see or manage the products it took over, and the public catalogue lists them under a supplier that no longer exists.

Needs a live check

Code reading. Confirm by merging a supplier with at least one module and one service in a test instance and reading their provider afterwards.

Surfaced by the capability matrix in stackiq#1072 (merge 38b9938), rows org-merge and land-duplicate-merge.

[github-actions]

Thank you for opening this issue! It has been assigned to @rubenvdlinde for review.

What happens next:

1. A maintainer will review this issue and determine the appropriate action
2. If accepted, it may be converted into an OpenSpec change for structured development
3. You will be notified of any status changes

Triage labels:

• triage:accept-feature — accepted as a new feature
• triage:accept-bugfix — accepted as a bug fix
• triage:needs-info — more information needed
• triage:wontfix — will not be addressed
• triage:duplicate — duplicate of another issue