bug(refs): resolve group statuses from /person/masterdata instead of treating #67 as permanent

[bwl21]

Problem

The warning and resolver behavior introduced after #67 are based on an incomplete API audit. ChurchTools does expose a REST catalog for numeric groupStatusId values:

GET /person/masterdata

The response contains data.groupStatuses, with stable technical names and the instance-local numeric IDs.

This was verified live on 2026-08-27 with:

• ct-cli: 3.7.0-dev.16+f2c8724
• ChurchTools: 3.136.0-RC16

Relevant response excerpt:

{
  "groupStatuses": [
    { "id": 1, "name": "active",   "nameTranslated": "Aktiv",      "sortKey": 10 },
    { "id": 2, "name": "pending",  "nameTranslated": "Entwurf",    "sortKey": 20 },
    { "id": 3, "name": "archived", "nameTranslated": "Archiviert", "sortKey": 40 },
    { "id": 4, "name": "finished", "nameTranslated": "Beendet",    "sortKey": 30 }
  ]
}

The current OpenAPI schema also defines PersonMasterData.groupStatuses as an array of GroupStatus objects with id, name, nameTranslated, and sortKey.

Current behavior

A dynamic ruleset containing numeric group status IDs produces warnings such as:

dynamic group "ojbp_2026_27": ruleset carries 3 host-specific id(s) — not portable to another instance:
  ctgroup.groupStatusId: 1, 2, 4 left numeric — group statuses have no REST catalog (#67) — no logical form exists

The statement “group statuses have no REST catalog” is therefore no longer correct. The probes documented in #67 checked dedicated endpoints such as /group/statuses, but missed the catalog embedded in /person/masterdata.

Expected behavior

ct-cli should use /person/masterdata.data.groupStatuses as the group-status catalog:

• resolve logical group-status references by technical name to the target host's numeric ID;
• reverse-resolve numeric ctgroup.groupStatusId values in adopted dynamic rulesets to logical references;
• avoid the non-portability warning when every numeric ID can be resolved;
• retain an actionable warning/fallback only for IDs absent from the live catalog;
• update the API coverage documentation and comments that currently cite bug(refs): group-status sugar resolves against /group/memberstatus — the wrong dimension (member statuses, string ids); no REST group-status catalog exists #67 as proof that no catalog exists.

Acceptance criteria

• A config/ruleset using logical statuses such as active, pending, and finished resolves through the selected environment's live groupStatuses catalog.
• Tests cover two hosts with different numeric IDs for the same technical status names.
• Reverse resolution converts known numeric IDs to logical references and preserves unknown IDs with a warning.
• Existing numeric groupStatusId input remains backward compatible.
• Documentation distinguishes group statuses from both /group/memberstatus and person/community /statuses.

Related: #67.