resolve_polity_label() documents 225 dangling aliases that the build makes impossible: every count in that paragraph is stale

resolve_polity_label()'s roxygen (R/polities.R, just above @param label) carries a paragraph of counts that no longer describe the package:

#' A resolved code names a polity in the published upstream database, which is
#' ahead of the [polities] snapshot this package ships (740 rows upstream against
#' 603 here). 225 of the 869 published aliases therefore point at one of 115
#' codes [get_polity_geometries()] cannot yet return a row for; refreshing
#' [polities] closes that gap without changing any resolution.

Every number in it is wrong, and the claim it makes is the opposite of the truth.

Measured on main after the #767 re-sync (whep-polities 2830fb7):

claim in the doc	actual
869 published aliases	903
603 polities shipped, 740 upstream	757, and upstream is the same 757
225 aliases point at a code get_polity_geometries() cannot return	0
115 such codes	0

The gap cannot be non-zero by construction, which is what makes the paragraph actively misleading rather than merely out of date: data-raw/table_mappings.R aborts the build if any alias names a polity the GeoPackage does not carry —

unknown_alias_targets <- setdiff(
  polity_label_aliases$polity_code,
  polities$polity_code
)
if (length(unknown_alias_targets) > 0L) {
  cli::cli_abort(c(
    "The published label alias map targets polities this package cannot carry.",
    ...

— because both artifacts are read from the same upstream revision. So a reader told to expect 225 dangling aliases and to "refresh polities" to close the gap is being sent after something that cannot happen.

It was already stale before #767 (that PR moved 869 → 903 and 753 → 757, but the dangling count was 0 on either side).

What to do

Replace the paragraph with the invariant instead of a snapshot count: the alias map and the polities table are regenerated together from one upstream revision and the build refuses to ship them from different ones, so every resolved code is one get_polity_geometries() can return. No number to go stale.

Why it is filed separately

R/polities.R is owned by #763 in the current wave; #767 measured this while re-syncing data/*.rda and deliberately did not touch the file.

Found while doing #745 / #767. Part of the polity migration epic #458.