Add UK support to the CLI

[leenyburger]

Adds UK enablement on top of the already-merged API v2 migration (#4). The v2 work handled the version/response-shape bump; this PR adds the UK-specific layer it didn't touch.

Closes ENG-1080

Changes

• distance --country now accepts united kingdom / great britain (case-insensitive) → appends "United Kingdom". Follows the existing strict full-name convention, so two-letter gb/uk are ignored with a warning, just like us/ca are today. Both the distance and distance-matrix warning messages updated.
• geocode --country usage text: (US or CA) → (e.g. US, CA, GB). No logic change — the flag is forwarded as the API country hint, which already fuzzy-matches GB/UK server-side.
• Docs (README.md, bundled skills/geocodio/SKILL.md): document GB country usage and the UK field appends (uk-westminster(-next), uk-devolved(-next), uk-local(-next)). Also added the previously-missing --country row to the distance flags table.
• CLAUDE.md: fixed a stale v1.9 base-URL reference left over from the v2 migration (now v2).

Tests

• New UK cases in TestAppendCountry (incl. GB rejected, matching the strict convention).
• gofmt clean · go build ./... · go test -race ./... all pass · go vet clean.

UK geocoding is gated server-side by the access-gb-geocoding entitlement; this PR is purely the client-side UX/docs to make UK usable from the CLI.

[leenyburger]

Summary

Clean, small, well-scoped PR. It adds "United Kingdom" as a third accepted value for the --country flag, documents UK-specific data-append fields, and fixes a stale v1.9 base-URL reference in CLAUDE.md. The core change — one case "united kingdom" arm in normalizeCountry — is correct and backed by three new test cases (full name, case-insensitive, and an invalid-GB-ignored case) that match the implementation. Nothing here looks risky.

Findings

1. Stale doc comment on appendCountry (medium — should fix)
internal/cli/distance.go:14-15 still reads:

// appendCountry appends the country to an address if it's not already present.
// Only accepts "USA" or "Canada" (case-insensitive). Other values are ignored.

This now also accepts "United Kingdom". The PR updated the user-facing warning strings and README but missed this comment. One-line fix.

2. distance/distance-matrix flag help wasn't updated (low)
distance.go:77 and distance.go:142 still show Usage: "Country to append to addresses (e.g. Canada)", while the README now documents this flag as accepting USA, Canada, or United Kingdom, and geocode's help string was updated to list all three. The in-CLI --help for distance is now less informative than the docs. Worth aligning for consistency (e.g. "(e.g. USA, Canada, United Kingdom)").

3. Behavioral divergence between geocode and distance country handling (low — pre-existing, but this PR sharpens the mismatch)
The two commands treat --country differently:

• geocode passes the raw flag value straight to the API as a country query param (geocode.go:75), with no normalization or validation — --country GB or --country foo is sent as-is.
• distance/distance-matrix run the value through normalizeCountry, append it to the address text, and warn+ignore anything not in the allowed set.

So geocodio geocode … --country GB silently forwards GB, while geocodio distance … --country GB warns and drops it. The divergence is intentional (geocode's API accepts a hint; distance only takes free-form address strings), but this PR's new geocode usage string — "Country hint (e.g. USA, Canada, United Kingdom)" — now implies a curated set that geocode doesn't actually enforce. Not a blocker; just flagging that the help text suggests validation that only distance performs.

4. UK append-field names are unverified documentation claims (informational)
The README/SKILL.md list uk-westminster, uk-westminster-next, uk-devolved, uk-devolved-next, uk-local, uk-local-next. These are pass-through --fields values, so the CLI doesn't validate them — correctness depends entirely on those matching the live API field IDs. Worth a quick confirmation against the Geocodio v2 docs, but nothing the code can enforce.

Verification note

Build/tests were not run in this review (go was unavailable in the review environment). The test logic is simple enough to verify by inspection and is consistent with the implementation, but CI / a local make test should confirm the suite is green.

Bottom line: Approve-with-nits. Only finding #1 (the stale comment) is worth fixing before merge; the rest are minor consistency polish.

[MiniCodeMonkey]

Thanks for catching this and making the changes. Especially the v2 migration misses!

It all looks good! Only thing I would flag, is that I would strongly prefer if we removed client-side country validation.

We should be able to add support for new countries in the future without having to update the CLI to enable support.

On the server-side, we support a large array of country formats, e.g. "USA", "US", "United States", etc. so there's no need to normalize on the client-side either.