Supported way to update or remove a fulfillment's delivery address (for data-deletion requests)

[Antonio313]

What we need

A supported way to update or remove a fulfillment's delivery_address (the fulfillment_address row), so a store can erase a customer's personal details when the customer deletes their account.

Why

Data protection laws (GDPR, and similar ones elsewhere) let customers ask for their personal data to be deleted. A store usually keeps past orders for tax and accounting, but removes who the customer was. In Medusa 2.x we can do that for orders: updateOrders and updateOrderAddresses let us clear the email, the customer link and the address down to region and country.

Shipments are the gap. createOrderFulfillmentWorkflow copies the order's shipping address into the fulfillment's delivery_address (name, phone, street). After the order is anonymised, that copy still holds everything.

What we found (Medusa 2.21.2, and 2.22.1 is the same)

• UpdateFulfillmentDTO has no delivery_address, and the fulfillment module deliberately doesn't generate methods for Fulfillment or FulfillmentAddress ("Not adding Fulfillment to not auto generate the methods under the hood"). The address service is internal to the module.
• updateFulfillment(id, { delivery_address: { id, first_name: null, ... } }) is silently ignored.
• updateFulfillment(id, { delivery_address: { first_name: null, ... } }) (no id) passes through to the ORM: it creates a new address row and repoints the fulfillment, but the old row stays in fulfillment_address, untouched and not soft-deleted. So the personal data is hidden, not removed, and the old row is left orphaned. This looks unintended, and we're not relying on it.
• Raw SQL against a module's tables isn't something we want to do in a Medusa app.

Possible shapes

Any of these would solve it:

1. delivery_address in UpdateFulfillmentDTO, updating the existing row in place (by its id).
2. An updateFulfillmentAddresses (and ideally deleteFulfillmentAddresses) method on the fulfillment module service, like the order module's updateOrderAddresses.
3. A core workflow or step to anonymise a fulfillment's address, which data-deletion workflows could reuse.

Happy to test a change against a real store if that helps.