Checkout block rejects legacy 4-digit Argentine postcodes (e.g. 1213) since 11.2.0 #69643

Describe the bug

Since WooCommerce 11.2.0, the Checkout block rejects 4-digit Argentine postcodes such as 1213 (CABA) with "Please enter a valid postcode". Argentine merchants lost orders after updating and had to roll back to 11.1.x.

Related: #66953 (unify postcode validation), PR #67780 (milestone 11.2.0, introduced the regression).

Root cause

Argentina (AR) is not in i18n/postcode-validation-rules.json, so isPostcode() falls back to the postcode-validator package regex. PR #67780 bumped the package from 3.9.2 to 3.10.22, and the AR rule changed:

• 3.9.2 / WC 11.1.2 bundle: ^([A-HJ-NP-Z])?\d{4}([A-Z]{3})?$ (province letter optional)
• 3.10.22 / WC 11.2.0 bundle: ^[A-HJ-NP-Z]\d{4}([A-Z]{3})?$ (province letter required)

Both regexes were found in the compiled blocks bundles of the wordpress.org zips. The legacy numeric format is still in everyday use in Argentina. Server-side WC_Validation::is_postcode() has no AR rule and the Store API accepts the value, so only the client-side check blocks it (same client/server divergence as #68920).

Steps to reproduce

1. WooCommerce 11.2.0 on a clean WordPress 7.1.3 / PHP 8.3 install (WordPress Playground), store country Argentina, state CABA (AR:C), Checkout block, any product in the cart.
2. Go to the checkout and enter 1213 in Postcode / ZIP, then move out of the field.
3. The field shows "Please enter a valid postcode" and the validation store has billing_postcode set.

Results (same steps, same data)

Store API on 11.2.0: POST /wc/store/v1/cart/update-customer with AR / C and 1213 returns 200 and stores 1213.

Expected

1213 (and other plain 4-digit codes) accepted, as in 11.1.x.

Suggested fix (not tested)

Add an explicit AR rule to COMPATIBILITY_OVERRIDES in client/blocks/bin/generate-postcode-validation-rules.js, for example AR: { pattern: '[A-HJ-NP-Z]?[0-9]{4}(?:[A-Z]{3})?', flags: 'i' }, regenerate the JSON and add fixtures. Other countries not in the override list may have changed behaviour with the package bump and are worth auditing.

Impact

Support ticket: merchant in Argentina lost sales while on 11.2.0 and is pinned to 11.1.2 (Zendesk 11783139). Workaround: stay on 11.1.x.

Environment

WooCommerce 11.2.0 vs 11.1.2 (wordpress.org zips), WordPress 7.1.3, PHP 8.3, default Checkout block, Cash on delivery enabled.