Complete the Provinces feature: Shop API, Dashboard UI, zone membership and seeding

[TheHypnoo]

Summary

The Regions & Provinces work (7b8f5bf6a, closing #76) landed the data layer and the Admin API, but the product surface around it was never built. Provinces are real entities with full Admin API CRUD, and there is no way to reach them from the product itself — only by hand-writing GraphQL calls.

The clearest illustration: that commit shipped a BREAKING CHANGE note stating "Zones may now be composed of both countries and provinces", and #76 was closed as completed with US state-level sales tax as its headline use case. There has never been a UI to create a province or to add one to a Zone — git log --diff-filter=A -- 'packages/admin-ui/**/*province*' is empty, and the same is true of the Dashboard. So the capability exists in the schema and is unreachable in the product.

#4792 / #4857 fixed one part of this (the entity and service weren't even exported from @vendure/core). This is the rest of the follow-up work that issue asked for. I'd like to implement it — happy to split into separate PRs against minor.

What exists today

• Region (abstract, single-table inheritance) → Country + Province — packages/core/src/entity/region/
• ProvinceService with full CRUD — packages/core/src/service/services/province.service.ts
• Admin API CRUD — packages/core/src/api/schema/admin-api/province.api.graphql
• ProvinceEvent on the EventBus
• Exports and DI registration (fix(core): Export and register Province entity and ProvinceService #4857)

Gaps

1. Shop API does not expose provinces.
shop.api.graphql has availableCountries: [Country!]! and nothing else. There is no Country.provinces field and no availableProvinces query, so a storefront cannot populate a state/province selector from Vendure — the data is in the DB and unreachable without the Admin API.

2. No Provinces UI in the Dashboard.
src/app/routes/_authenticated/ has _countries and _zones but no _provinces. The only way to create a province is a raw createProvince mutation. Same in the Angular Admin UI (packages/admin-ui/src/lib/settings/src/components/ has country-detail/country-list, no province equivalent).

3. Zones cannot take provinces as members in the UI.
Zone.members is typed Region[], so the data model already supports it — but the Dashboard is wired country-only (zone-countries-sheet.tsx, zone-countries-table.tsx, addCountryToZone). This blocks the common case of US state-level tax zones, which is what #4792 originally hit.

4. InitialData cannot seed provinces.
InitialData has countries: CountryDefinition[] and Populator.populateCountries(), with no province counterpart. New projects start with zero provinces and no supported way to bulk-load them.

Proposed scope

Additive only, targeting minor:

1. Shop API: Country.provinces and/or availableProvinces, respecting enabled.
2. Dashboard: Settings → Provinces list/detail, mirroring the existing Countries routes, with the parent country on the province.
3. Dashboard: allow adding provinces to a Zone alongside countries (addRegionToZone-style, or extend the existing member selector to Regions).
4. InitialData: provinces: ProvinceDefinition[] + Populator.populateProvinces(), parented by country code.

Angular Admin UI parity for 2 and 3 is in scope if maintainers want it; otherwise Dashboard only.

Deliberately out of scope

Address.province is a plain string column with no FK to Province and no validation. Turning it into a relation would be a breaking change (major) and a data migration, and it deserves its own discussion rather than riding along with the additive work here. Raising it only so it's on the record.

Happy to start with whichever piece is most useful, once the shape is agreed.

[michaelbromley]

Just to confirm: it was implemented as a foundational data model change back then with the idea that we would bring in support for things like nested locations (Country -> Province -> County etc) but was never worked on past that.