feat: permissions ergonomics — domainId by reference, grant adoption, catalog lifecycle

[2000game]

Round off permissions-as-code (#13) for real operation: today domainId is a hand-supplied number, grant adoption shipped but is broken for non-group scopes (#49), and the name→authId catalog (src/permissions/catalog.json) is a one-off HAR-trace artifact of a single CT version with no staleness detection. Part of the Phase 6 epic.

Scope

• domainId by reference: declare domains as { group: "mainz_kids_lead", role: "Leiter" } / { groupType: "ministry_team", role: "Leiter" } and resolve to the numeric domainId live. Prerequisite: freeze the group_role domainId semantics (Phase 5 spec open item 2 — role-definition id vs per-(group,role) pairing id; the code comment says pairing id, confirm on eqrm-dev and pin with a test). The shared resolver this needs exists (feat: portable configs — logical references instead of numeric CT ids (shared resolver) #20, merged).
• Adopt grants — done (PR feat: ct adopt grants — emit paste-ready permission config from live rows (#25) #45): ct adopt grants <domainType> <domainId> reads live user-authored grants (baseline/inherited excluded) and emits the grants: block. Residual bug: churchdb grants scoped to non-group dataIds are misclassified — tracked as bug(permissions): ct adopt grants assumes every scoped dataId is a group #49, blocks plan-to-no-op on prod.
• Catalog lifecycle: script to regenerate catalog.json from the legacy churchauth getMasterData call against a live instance; record the CT version the catalog was captured from inside the file; ct plan warns when the instance version ≠ catalog version or when an actual grant carries an authId unknown to the catalog (today that's an unexplained diff).
• Later / stretch: expose type: "revoke" authoring (valid for group_role only — GrantTuple already models it, DSL never emits it).

Acceptance criteria

• A permission grant is declared with zero numeric ids (right name + group/role/groupType keys) and reconciles idempotently.
• Adopting an existing role's grants → generated config block → ct plan no-op.
• Catalog regeneration is one documented command; stale/unknown-authId situations warn instead of confusing the diff.

[2000game]

Grant adoption merged (PR #45): ct adopt grants <domainType> <domainId> emits a plan-safe config block — every emitted grant is guaranteed accepted by ct plan; inexpressible rows (group_type_role authId >= 10000, globally-granted scoped rights, unknown authIds, unmanaged scope targets) become NOTE/WARNING comments with an explicit pending-revocation warning. Remaining scope for this issue: domainId-by-reference (waits on #20 — the group_role (group,role) pairing-id lookup is gated on confirming a live endpoint) and catalog lifecycle (regen script + version staleness check).