[6.x] Fix Addresses fields not reading the posted form value

[brianjhanson]

Description

Addresses::formControl() renders the field with the Matrix form control, which posts its value as {"entries": {…}, "sortOrder": […]}, but Addresses::createAddressesFromSerializedData() still expected the legacy flat [addressId => data] shape. It iterated the envelope's own keys, so every save fabricated one blank address per key — always exactly two — and never applied removals or edits.

The user-visible symptom: removing every address from an entry left two blank addresses attached, and the entry could no longer be saved ("Validation errors found in two addresses within the Address field").

createAddressesFromSerializedData() now reads the same format Matrix::_createEntriesFromSerializedData() does — the entries/blocks/sortOrder envelope, addresses keyed by UUID (with or without the uid: prefix), and the canonical→derivative UUID map so draft autosaves match up their addresses instead of recreating them. New addresses keep their posted UUID, and the address format attributes the Address control nests under address are applied alongside the top-level native attributes. The legacy flat format still works.

normalizeValueFromRequest() also now treats a null value as "every address was removed", matching the Matrix fix in 42516a1 — Laravel's ConvertEmptyStringsToNull middleware turns the '' sentinel into null before the field sees it.

[github-actions]

📚 Storybook previews

@craftcms/ui — open Storybook

No changed components detected in this Storybook.

resources/js — open Storybook

No changed components detected in this Storybook.