[Shipping labels] Display remote validation errors in address form

[rachelmcr]

Part of: #13781
⚠️ Depends on #15023 ⚠️

Description

This updates the Woo Shipping label edit address form to display validation errors from the remote endpoint.

There are two changes in the behavior:

1. If we receive an error specific to an address field (e.g. name or address error) we display it inline, under the field.
2. If we receive a general error, we display it at the bottom of the screen (instead of the verified/unverified status).

Changes

• Updates WooShippingAddressField to include a method to set an error message, so we can set a remote validation error on a field.
• Updates WooShippingEditAddressView to get the status label from the view model.
• Updates WooShippingEditAddressViewModel with a statusLabel property.
  • When an error is received from the remote validation endpoint, and it's a general validation error, we save that error in remoteValidationError. If it's a field-specific error, we set the error on the corresponding field.
  • If there are no validation errors, this shows the address status (verified, unverified, missing information).
  • If there is a general error, and there are local changes that need to be validated and saved, this shows the error message.

Testing information

1. Ensure the latest production version of WooCommerce Shipping (Version 1.3.2) is installed, activated, and set up on your store.
2. Create or open an order with at least one physical product and the processing status.
3. Tap "Create Shipping Label" in order details.
4. Open the "Shipment details" bottom sheet.
5. Tap the "Ship from" origin address.
6. Tap the edit (pencil) icon on one of the origin addresses.
7. In the edit address sheet, update the address fields to a non-existent address. (You can remove the house number from the address field to ensure a field-specific error.)
8. Tap "Validate & Save" and confirm the validation errors are shown.

Screenshots

Simulator.Screen.Recording.-.iPhone.16.Pro.-.2025-01-30.at.16.02.05.mp4

---

• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

Reviewer (or Author, in the case of optional code reviews):

Please make sure these conditions are met before approving the PR, or request changes if the PR needs improvement:

• The PR is small and has a clear, single focus, or a valid explanation is provided in the description. If needed, please request to split it into smaller PRs.
• Ensure Adequate Unit Test Coverage: The changes are reasonably covered by unit tests or an explanation is provided in the PR description.
• Manual Testing: The author listed all the tests they ran, including smoke tests when needed (e.g., for refactorings). The reviewer confirmed that the PR works as expected on all devices (phone/tablet) and no regressions are added.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce iOS by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce iOS
	Build Number	pr15024-6177844
	Version	21.5
	Bundle ID	com.automattic.alpha.woocommerce
	Commit	6177844
	App Center Build	WooCommerce - Prototype Builds #12742

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[toupper]

The PR tests well 👍

I noticed something that may not be related to this PR: when I start editing the Address field, the Done-Prev-Next toolbar isn’t fully attached to the bottom, allowing the scroll view to be visible. Tested with the simulator iPhone 16

[toupper]

LGTM and tests well! 🚢

[wpmobilebot]

Version 21.6 has now entered code-freeze, so the milestone of this PR has been updated to 21.7.

[rachelmcr]

I noticed something that may not be related to this PR: when I start editing the Address field, the Done-Prev-Next toolbar isn’t fully attached to the bottom, allowing the scroll view to be visible. Tested with the simulator iPhone 16

We set the toolbar location with ToolbarItemGroup(placement: .keyboard), so the way it appears with a hardware keyboard doesn't seem to be something we can directly control. We could try adding an inset to the bottom of the screen so the scroll view doesn't stretch all the way to the bottom, but I'm not sure if that could cause issues in other ways.

I expect that users with a hardware keyboard are relatively unlikely, and it's pinned to the keyboard as expected with the software keyboard, so I'd lean toward accepting it as-is rather than spending more time on it.