feat: resync onto upstream master, keeping the Mooncard data additions

[DamienMetzger]

Why

The fork was 168 commits behind upstream on a reference-data gem. ISO country codes, subdivisions, currencies and VAT data change over time, so being 19 months stale here is a correctness question, not hygiene. Three repos resolve it: mooncard, mooncard-service-stations, mooncard-ariane.

Your changes all survive — and upstream still has none of them

Checked against upstream/master (1dd3015, 2026-09-05), not assumed:

Mooncard addition	Upstream today
XK.yaml — Kosovo as XK/XXK	no XK file at all
RO.yaml unofficial_names += ROM	has alpha3: ROU only
CD.yaml unofficial_names += ZAR	has alpha3: COD only
XK: Kosovo in countries-en/fr	absent

Rebuilt, not rebased

Of the 8 commits the old fork carried, 4 were regenerated cache plus a two-step case-rename dance (xk.yaml → XK-upcase.yaml → XK.yaml, needed on case-insensitive filesystems). Only 4 were source.

Merging generated files is how a resync becomes a week of conflicts, so this branch is built fresh on upstream/master with the 4 source changes re-applied, and the cache regenerated by the repo's own rake update_cache. Net diff: 10 files.

The one judgement call

Four spec assertions now expect NUM_OF_COUNTRIES - 1.

Upstream changed these specs to test locale 'pt'; they previously called the no-argument form, which is English — where Kosovo exists. With Kosovo added and only en/fr names for it, a locale lacking an XK translation returns one fewer.

The alternative was writing Kosovo into all 131 translation files. I rejected that — it would invent translations for 129 locales where the real name differs (Albanian Kosova, Serbian Косово), purely to make an assertion pass. Upstream's own comment, two lines above each assertion, already says countries missing the desired locale are not added to the list.

Happy to switch to per-locale translations if you'd rather, but that's real data someone has to source.

Verification (in the workspace container)

• ✅ 280 examples, 0 failures — 4 failures before the spec adjustment
• ✅ line coverage 100%
• ✅ ISO3166::Country.new("XK") → "Kosovo", alpha3 XXK
• ✅ find_country_by_unofficial_names("ROM") → RO
• ✅ find_country_by_unofficial_names("ZAR") → CD
• ✅ translation("fr") → "Kosovo" once :fr is in ISO3166.configuration.locales
• ✅ 250 countries; cache regenerated, XK in countries.json, en.json, fr.json

Deploy order

This must merge first. The three consumers then re-pin to the new master revision — one PR each, raised after this lands.

🤖 Generated with Claude Code

[DamienMetzger]

Conflicts resolved in c35a0e9.

Why they happened

This branch was rebuilt on current upstream (1dd3015, 2026-09-05) rather than rebased, so it shared no recent history with the fork's master. Both sides then touched the same seven files — and that is exactly the conflict you'd expect.

Why -s ours is the right resolution here, not a shortcut

I checked what origin/master actually had that this branch lacked before deciding. It is 10 commits: the 8 original Mooncard commits plus 2 upstream merges from 2025-02. Outside the regenerated cache they touch precisely seven files:

lib/countries/data/countries/CD.yaml
lib/countries/data/countries/RO.yaml
lib/countries/data/countries/XK.yaml
lib/countries/data/translations/countries-en.yaml
lib/countries/data/translations/countries-fr.yaml
spec/country_spec.rb
spec/data_spec.rb

Every one of those changes is already on this branch, re-applied on top of a 19-months-newer upstream. So origin/master's only unique content is the stale version of the same four additions — taking any of it would move the fork backwards.

The merge is recorded (not discarded) so the history stays connected and the old commits aren't orphaned.

Verified after the merge, not assumed

• ✅ tree byte-identical to the pre-merge tree — the merge changed nothing
• ✅ XK.yaml present · RO.yaml has ROM · CD.yaml has ZAR · XK: Kosovo in both translations
• ✅ 250 country files; XK in the regenerated cache
• ✅ 280 examples, 0 failures, coverage 100%
• ✅ mergeable=MERGEABLE, state=CLEAN