feat(permissions): portable scope refs + declarable person statuses

[2000game]

Closes #96 and #98 — two instances of the same shape: a permission domain that
looks portable but silently isn't, so a config that plans clean on one host
breaks (or misgrants) on the next.

#98 — typed logical scope refs

A scoped grant's scope now takes a typed reference alongside the group key and
the numeric dataId:

{ right: "churchdb:view station", scope: [{ campus: "koblenz" }] }
{ right: "churchgroup:view groups of grouptype", scope: [{ groupType: "struktur" }] }
{ right: "churchdb:view alldata", scope: [{ department: "outreach" }] }

{ campus: "x" } is sugar for ref.campus("x"), so both spellings are identical.

scopeField	Reference	Resolved against
cdb_gruppe	{ group: "…" } / bare string	managed groups
cdb_station	{ campus: "…" }	managed campuses → /campuses
cdb_gruppentyp	{ groupType: "…" }	managed group types → /group/grouptypes
cdb_bereich	{ department: "…" }	/departments (read-only)

Why it matters. These ids are host-specific, so the numeric literal that was
previously the only option is a cross-environment misgrant — and because
declaring a domain makes ct own it, a wrong-scope grant doesn't merely add
the wrong thing, it revokes the right thing on the other host.

Ref resolution is hoisted into one async pass (resolveScopeRefs) so per-grant
resolveScope stays synchronous; tuples carry scopeType so apply-time
re-resolution checks the right resource type.

Three hard errors at plan time, never a guessed dataId:

• a ref whose dimension doesn't match the right's scopeField (names both);
• a ref on a dimension with no logical form (points at the numeric hatch);
• a bare string on a non-group dimension — a latent bug this surfaced. A
  string always meant "managed group", so on e.g. a cdb_station right it either
  failed confusingly or matched an unrelated group carrying that key.

ct adopt grants emits typed refs for managed campus/group-type dataIds, and a
NOTE naming the one command that makes the rest portable.

#96 — person statuses are declarable

Adds a person-status resource kind: ct.personStatus, ct adopt person-status <id>, ct get statuses. A personStatus: domain now resolves from managed
state before the /statuses catalog, so a status declared in the same config
resolves to a pending domain and converges in one ct apply.

Previously the resolver's own advice was impossible to follow:

✗ Cannot resolve person-status:3 - Group Active … no managed resource and no live
  person-status at /statuses matches key "3 - Group Active".
  Declare/adopt it, fix the key/name, or use a numeric id.

Statuses are master data (the enumeration), never person records — the people
boundary is untouched and asserted in tests.

Verified against a live instance, not assumed

Endpoint facts read from the instance's own OpenAPI spec (CT 3.135.2):

• /departments is GET-only — no POST/PUT/DELETE, no item path. This
  settles the fork feat(permissions): portable scope refs for non-group dimensions (cdb_station, cdb_bereich, cdb_gruppentyp) #98 left open: departments are a read-only ref catalog,
  referenceable by name everywhere but never declarable, and an unknown name
  hard-errors saying exactly that.
• /statuses PUT requires all six of name, shorty, isMember, isSearchable, sortKey, securityLevelId, and is a full replace — uniquely strict among
  managed types (every other managed PUT declares no required fields). This
  caught a real bug in the first cut of feat(resources): person statuses are not declarable — the status permission domain is only half-portable #96: the narrow {name, shorty} set
  would have 400'd on every update, or blanked the omitted fields. The registry
  now manages all six and declares no createDefaults.

Also: the #25 group_role assumption is retired

The pairing-id model has carried an ASSUMPTION — verify once on a live instance block since #25. Verified against two anchors on different group
types, each chosen so the per-group id and type-level groupTypeRoleId
necessarily differ:

• both role rows' ids are live group_role domainIds carrying that role's
  authored grants;
• neither row's groupTypeRoleId appears anywhere in the domainId set —
  decisive, since a type-scoped key would have to;
• roles with no authored rights have no domain at all, exactly as a
  per-(group, role) pairing predicts.

GROUP_ROLE_ENDPOINT and GROUP_ROLE_PAIRING_FIELD were already correct and are
unchanged; only the comment, handbuch callout and runbook row move to "verified".

Notes for review

• Backward compatible. Bare-string group scopes, numeric dataIds and every
  id: escape hatch behave exactly as before. The only new rejection is a bare
  string on a non-group dimension, which could not previously resolve correctly.
• docs/handbuch/ pages re-read and re-signed; docs/api-coverage.md gains rows
  for ct_person_status and ct_department; the runbook's group_role row flips
  to "verified live" and gains a Bereich row.
• 612 tests pass (35 new across two files), typecheck and lint clean.
• Per the repo's own rule that per-instance values belong in ct-structure, the
  docs and examples use neutral placeholders rather than real resource names.

https://claude.ai/code/session_01NiQXu3vCDVgHLbWxmgXoyJ