fix(permissions)!: address group_type_role by role, not by group type (#182)

[2000game]

Closes #182.

What was wrong

/permissions/group_type_role/<id> is keyed by role id. ct.groupTypeRole({ groupType }) resolved the group type id and used that as the domain, so it addressed whichever role happened to share the number.

Read live on 2026-09-26 (/group/roles against .ct/ids.<host>.json in eqrm/ct-structure):

Declaration in ct-structure	prod hits	dev hits
struktur_roles (33 grants)	Group / Leiter	no role
flow_roles (8)	Group / Mitglied	no role
newsletter_roles (15)	Team / Mitglied	no role
connectgruppe_roles (16)	Team / Leiter	no role
commitment_roles (declared empty)	no role	Struktur / leader
community_roles_empty	no role	Merkmal / Leiter

Prod has not been mis-written, because every set was adopted from live and round-trips. Dev is the risk: the two empty declarations own real roles there, so the next ct apply --env dev would revoke their grants.

The change

• ct.groupTypeRole takes groupType + role. The pair resolves through the existing ref.groupTypeRole resolver (slug match within the type, ambiguity error, /group/roles catalog).
• A bare groupType is an eval-time error that points at group_type_role resolves a group TYPE id where the API expects a ROLE id — struktur_roles manages Group-Leiter #182. There is no type-wide grant set in ChurchTools to default to.
• ct adopt grants group_type_role <id> now says in its comment that the id is a role id and names the portable form.
• Docs: handbuch/permissions.md (domainId semantics, examples, the same-run note), ci.md, runbook-manual-surface.md.

Breaking: this ships as v4.0.0. eqrm/ct-structure pins ^3.10.1 and moves to v4 in the same PR that rewrites its 13 declarations per role.

Not in this PR

• ct report permissions undercounting type-level roles (eqrm/ct-structure#107). That is a separate path in src/reports/.
• The other known doc errors (group-status catalog, /dbfields, group-type change, README). They go in their own docs PR.

Verification

• vitest: 1196 passed. The tests that encoded the old reading now assert the role id, using a fixture where the type id and a foreign role id collide on purpose.
• tsc --noEmit, eslint, prettier --check are clean.

Review (2026-09-26)

A /code-review high pass found 10 things. The code-level ones were checked with a throwaway plan test against this head, not only by reading.

Fixed here (88f940b):

• The planner still let the group_type_role resolves a group TYPE id where the API expects a ROLE id — struktur_roles manages Group-Leiter #182 bug through. resolveDomainIds resolved a group-type Ref for a group_type_role domain to the type id, and tests/permission-pending-domain.test.ts asserted exactly that PUT /permissions/group_type_role/<type id>. The planner now refuses it. The bug(permissions): domain-by-reference to a not-yet-created group type aborts the entire plan — fresh-instance rehearsal impossible #69 tests became a regression test (fails before, passes after), a test for the same-run limitation, and a typo test.
• The bug(permissions): domain-by-reference to a not-yet-created group type aborts the entire plan — fresh-instance rehearsal impossible #69 section of handbuch/permissions.md, the ci.md pending-domain bullet and the apply.ts comment still described group-type pending domains. They now name the real ones: person status (feat(permissions): manage the person-status grant domain (ct.status) #90) and group_role (bug(permissions): group + its own groupRole in one config can never plan on a fresh host (the domain half of #29) #106).
• "Until ct-cli 0.x" corrected to 3.x. Instance-specific type and role names and ids removed from the new comments and docs.
• ct adopt grants status <id> said "adopt the group…". Each domain type now names its own portable form, with a test.
• The blueprints.md snippet now uses groupType + role, matching examples/campus-blueprint.config.ts. The three stale handbook pages are re-read and re-signed.

Follow-up, #189: a same-run group type or role definition makes ct plan fail instead of going pending (confirmed). The old one-run path was never correct: it wrote to the type id. Also in #189: the ambiguity error's role-def advice can't be expressed in ct.groupTypeRole, and adopt could print the portable form directly.

main (#188) merged in; the runbook row conflict was resolved to keep both edits. 1195 tests, tsc, eslint, prettier, docs-staleness: all clean locally.