[Backport to release/11.2] Fix the Checkout block rejecting 4-digit Argentine postcodes - #69662

This PR is a cherry-pick of #69658 to release/11.2.

Original PR Description

Submission Review Guidelines:

• I have followed the WooCommerce Contributing Guidelines and the WordPress Coding Standards.
• I have checked to ensure there aren't other open Pull Requests for the same update/change.
• I have reviewed my code for security best practices.
• I have assessed the impact of this change and followed the applicable review requirements.
• Following the above guidelines will result in quick merges and clear and detailed feedback when appropriate.

Changes proposed in this Pull Request:

A shopper in Argentina who types a four-digit postcode such as 1213 in the Checkout block sees "Please enter a valid postcode" and cannot place the order. It happens since 11.2.0, while the Store API accepts the same value.

The Checkout block accepts the legacy four-digit Argentine codes again, as it did in 11.1.

• Why it happens: Argentina is not in the shared rules file, so the block falls back to the postcode-validator package. Unify postcode validation between PHP and Checkout blocks #67780 bumped it from 3.9.2 to 3.10.22, where the Argentina regex made the province letter mandatory. The server has no rule for Argentina.
• The fix pins the package back to 3.9.2. The shared rules are unchanged (the regenerated file differs only in its version line), so PHP validation does not move. It also undoes 21 countries that 3.10.22 started validating in the browser only; El Salvador, Saint Vincent and the British Virgin Islands were exposed the same way. Vietnam returns to the 11.1 rule, six digits only.
• Jest pins the Argentine fallback so the next bump fails CI instead of reaching shoppers. Sharing one rule set with the server is Share one postcode rule set across server and both checkouts #68244.

Closes #69643
Closes WOOPLUG-7949

Bug introduced in PR #67780.

How to test the changes in this Pull Request:

1. On a store with this branch built and Argentina as a selling location, add a product to the cart and open the Checkout block.
2. Pick Argentina and Ciudad Autónoma de Buenos Aires, type 1213 in Postcode / ZIP and leave the field. On trunk the field shows "Please enter a valid postcode"; with this PR there is no error and the order goes through.
3. C1213ABC is accepted on both; 142 still shows the error.

Testing that has already taken place:

• The new Jest cases fail on 3.10.22 (1213, 7540 rejected) and pass on 3.9.2; the validation and checkout form suites pass (291 tests).
• Regenerating the rules file on 3.9.2 changes only the generatedFrom.version line. pnpm install --frozen-lockfile passes. ESLint clean.
• Browser: WordPress Studio, WordPress 7.1.3, PHP 8.4, this branch built, store in Argentina with Cash on delivery and Free shipping. 1213 shows no error, the shipping options load, and the order is placed with postcode 1213 on both addresses. 142 shows "Please enter a valid postcode".
• No PHP changed; the PHP suites were not run.

Milestone

• Automatically assign milestone for the next WooCommerce version

Note: Check the box above to have the milestone automatically assigned when merged.
Alternatively (e.g. for point releases), manually assign the appropriate milestone.

Changelog entry

• Automatically create a changelog entry from the details below.

• This Pull Request does not require a changelog entry. (Comment required below)

Use of AI Tools

I used Claude Code for the investigation and the change, and I reviewed the diff.