Add - Pin the sanitize_key() collapse boundary at the rate-table seam.

state_compact_provider() already pins what the *projection* returns for a
collapsing state. Nothing pinned what that collapse does to the rate table, which
is the claim the changelog entry actually makes — and the reason the entry was
able to drift.

Adds two rows to provide_rate_table_round_trips(), which feeds both the round-trip
test and the matched-rates lookup test, so two rows are four cases:

  - 'state partially collapsing' (RO / 'ÎF', stored as 'F') is a regression test.
    Against the pre-migration space-stripping lookup both its cases fail: the
    round trip inserts a second row, and allow_street_address_for_matched_rates()
    cannot see the row create_or_update_tax_rate() had just written.

  - 'state wholly non-Latin' (RU / 'ЛЕН', stored as '') is a boundary
    characterization and passes with or without the migration. The blank matches
    the '' arm of core's `tax_rate_state IN ( %s, '' )`, so this shape never
    duplicated. It also pins that such an address yields a country-wide rate.

Together they are the narrowing: the same "non-Latin character" trigger, opposite
outcomes, decided by whether anything survives the stripping. Both cities are
plain ASCII on purpose, so the state dimension is not confounded with the separate
byte-parity contract to_find_rates_args() keeps with core.

Author: bartech

tests/php/test-class-wc-connect-taxjar-integration.php

@@ -3288,8 +3288,9 @@ public function provide_rate_table_round_trips() {
 			 * The same divergence, where space-stripping was not enough.
 			 * `sanitize_key()` drops the periods too, so the row was stored as `'NY'`
 			 * while both readers asked for `'N.Y.'` — nothing ever matched and every
-			 * calculation inserted a fresh row. Any state value carrying a character
-			 * outside `[a-z0-9_-]` behaved this way, non-ASCII included.
+			 * calculation inserted a fresh row. A state carrying a character outside
+			 * `[a-z0-9_-]` behaved this way only when something survived the stripping;
+			 * see the two cases below for the boundary that qualifier draws.
 			 *
 			 * `Address::state_compact()` now mirrors `sanitize_key()` rather than
 			 * approximating it, so the lookup asks for the value core actually stored.
@@ -3313,6 +3314,74 @@ public function provide_rate_table_round_trips() {
 				),
 			),
 
+			/*
+			 * The boundary the changelog entry has to respect: a state `sanitize_key()`
+			 * empties *outright* never duplicated a row, not even before the fix. Core
+			 * stores `''` and matches with `tax_rate_state IN ( %s, '' )`
+			 * (`WC_Tax::get_matched_tax_rates()`), so the stored blank satisfies the
+			 * second arm whatever the lookup asked for — the old space-stripping lookup
+			 * asked for `'ЛЕН'` and still found the row. The rate is country-wide, which
+			 * is a real behaviour worth pinning in its own right.
+			 *
+			 * Passes with and without the seam migration. That is what makes it a
+			 * boundary characterization rather than a regression test, and it is here so
+			 * the duplication story cannot be restated as "any non-ASCII state".
+			 *
+			 * The city is deliberately plain ASCII: this row is about the state
+			 * dimension, and a multibyte city would confound it with the separate
+			 * byte-parity contract `to_find_rates_args()` keeps with core.
+			 */
+			'state wholly non-Latin'           => array(
+				array(
+					'to_country' => 'RU',
+					'to_state'   => 'ЛЕН',
+					'to_zip'     => '190000',
+					'to_city'    => 'Saint Petersburg',
+					'from_state' => 'ЛЕН',
+				),
+				'Tax',
+				array(
+					'duplicates' => false,
+					'matched'    => true,
+					'country'    => 'RU',
+					'state'      => '',
+					'postcodes'  => array( '190000' ),
+					'cities'     => array( 'SAINT PETERSBURG' ),
+				),
+			),
+
+			/*
+			 * The shape that actually duplicated, and the reason the changelog says "a
+			 * character WooCommerce strips" rather than naming scripts. `sanitize_key()`
+			 * drops the diacritic and keeps the rest, so the row was stored as `'F'`
+			 * while the space-stripping lookup asked for `'ÎF'` — non-empty, different
+			 * from the stored value, and so matching neither arm of the `IN` clause. A
+			 * fresh row every calculation.
+			 *
+			 * Fails without the seam migration: two rows, and `first_id !== second_id`.
+			 * Paired with the case above, the two of them are the narrowing — same
+			 * "non-Latin character" trigger, opposite outcomes, decided by whether
+			 * anything survives the stripping.
+			 */
+			'state partially collapsing'       => array(
+				array(
+					'to_country' => 'RO',
+					'to_state'   => 'ÎF',
+					'to_zip'     => '077100',
+					'to_city'    => 'Buftea',
+					'from_state' => 'ÎF',
+				),
+				'Tax',
+				array(
+					'duplicates' => false,
+					'matched'    => true,
+					'country'    => 'RO',
+					'state'      => 'F',
+					'postcodes'  => array( '077100' ),
+					'cities'     => array( 'BUFTEA' ),
+				),
+			),
+
 			/*
 			 * A2's live half. The write sanitized the city with `wc_clean()` and the
 			 * lookup did not, so anything `sanitize_text_field()` removes made the two