● Issue #3412241: Reach base fields and dedupe the address_line3 update

address_update_9202() now discovers candidates via EntityTypeManager::getDefinitions() instead of getFieldMapByFieldType('address'). The field-map path is what 9201 already used and is the source of the original bug — it can miss address fields declared through BaseFieldDefinition or BundleFieldDefinition, which is why Profile, Group, Commerce Order Report, and custom entities were left with mismatched schemas.

Factored the per-field schema work out of 9201 into a private _address_install_add_line3_column() helper. Both update hooks now call it, so the ~100-line duplication is gone and the fieldExists() guard that makes 9201 idempotent automatically applies to 9202 as well.

Other cleanup in 9202:

• Removed the hardcoded $entity_type_id !== 'profile' filter, which silently excluded every entity type the issue reports.
• Removed the unreachable isset($field_schema['columns'][...]) fallback (the isset check ran after the key was already dereferenced on the preceding line).
• Dropped the unused &$sandbox parameter.
• Wrapped getStorage() in try/catch so a contrib entity type whose storage is unavailable doesn't abort the update.
• Added the missing trailing newline.

Test coverage (tests/src/Kernel/Update/AddressLine3UpdateTest.php):

• 9201 is idempotent when the column already exists.
• 9202 restores a dropped column on a configurable address field (dedicated-table path).
• 9202 is a no-op when nothing needs repair.
• 9202 restores a dropped column on a base address field (shared-table path) — the scenario the issue describes.

The base-field case is exposed via a new minimal test module, tests/modules/address_test_line3/, which adds a base address field to entity_test via hook_entity_base_field_info(). It is kept separate from the existing address_test module so no other tests are affected.

Closes #3412241