Add - Characterization tests for the TaxJar rate-table seam.

Golden-masters the `wp_woocommerce_tax_rates` round trip before
`create_or_update_tax_rate()` and `allow_street_address_for_matched_rates()`
are migrated onto the address value object. Duplicate rate rows are the
failure mode this seam produces, and they are silent — the right rate is
still charged, so nothing surfaces until the table has grown a row per
checkout. Every case therefore calls twice and asserts on the row delta.

Measuring the current behaviour corrected two of the three asymmetries the
refactor plan attributes to this seam:

- The postcode asymmetry (written through `wc_normalize_postcode()`, read
  raw) is real but unreachable: `WC_Tax::find_rates()` applies the identical
  `wc_normalize_postcode( wc_clean( … ) )` to its own argument, so core
  reconciles it. ZIP+4 round-trips today.
- The state asymmetry is the reverse of what the plan describes. Core's
  `prepare_tax_rate()` pushes `tax_rate_state` through `sanitize_key()`, so
  the column holds a *more* normalised value than either reader asks for.
  `'N Y'` round-trips only because `str_replace( ' ', '' )` coincides with
  `sanitize_key()` for a space; `'N.Y.'` inserts a fresh row every time.

Three defects are pinned as-is rather than fixed here, so that the fix
appears as a deliberate change to this file:

- a state carrying anything outside `[a-z0-9_-]` duplicates rows on every
  calculation;
- a city carrying anything `sanitize_text_field()` removes does the same,
  because the write applies `wc_clean()` and the lookup does not;
- `allow_street_address_for_matched_rates()` normalises the state not at all,
  so it cannot see rows that `create_or_update_tax_rate()` can — the
  `woocommerce_matched_rates` path silently returns no rates for those
  addresses while itemized cart totals stay correct.

Also pins the parts that must survive untouched: ordinal-position matching of
priorities, in-place rate updates, and the VAT branch writing no location rows.

Author: bartech