feat(schema): person master-data + security levels + custom field definitions

[2000game]

Adds the field-definition schema read surface for persons and groups, and records a writability decision. Schema/definitions only — the tool never reads or writes person records or per-record field values (the permanent people boundary, assertNotPeople).

What this adds

• ct get person-masterdata → GET /person/masterdata (single object, unpaginated): the person master-data model incl. the security-level enumeration that churchdb permission scopes (cc_securitylevel) reference.
• ct get data-fields → GET /dbfields (auto-paginated): the unified data-field DEFINITION catalog. Person master-data fields and group custom fields ("Datenfelder") live in one list, discriminated per-row by fieldCategory (table/internCode, e.g. cdb_gruppe = a group field). This one endpoint serves both feat: manage person master-data field definitions + expose security levels (schema, not people) #47 (person fields) and feat: support custom field definitions (group custom fields; person custom fields) #48 (group custom fields).
• Both follow the existing RESOURCE_PATHS pattern: --env aware, getAll pagination where list-shaped. Additive only (new specs), so it rebases cleanly against feat(dx): human-authorable configs — idiomatic adopt output, dynamic sugar, located errors, machine-only state, blueprints by default #52/bug: dynamic ruleset round-trip assumption unverified — CT-recomputed fields would cause perpetual diffs #36.
• docs/field-definitions.md (boundary + decision + evidence), runbook update (custom fields moved from "out of scope" to read-only supported; only per-record values stay out of scope), api-coverage addendum, README pointer.

⚠️ Finding: no committed OpenAPI schema

The brief assumed a committed src/api/schema.d.ts generated from a live instance. That file is git-ignored (.gitignore) and generated on demand by npm run generate:client — it is not in the repo, so endpoint methods could not be verified against this repo's schema, and hitting a live instance is forbidden. Paths/methods below were instead verified against ChurchTools' public API-client libraries (5pm-HDH churchtools-api @ CT 3.104, bensteUEM ChurchToolsAPI @ CT 3.101) and CT Academy docs. Re-verify per the runbook's re-audit procedure once a schema is generated.

Writability decision — READ-ONLY (both #47 and #48). No fake writability.

Field definitions are read-only; no registry resource / DSL is added. Evidence:

1. Every public CT REST client exposes data fields as GET-only — GET /dbfields, GET /dbfields/{id}. No REST POST/PUT/PATCH/DELETE on any field-definition path.
2. Mutation exists only via the legacy churchdb admin AJAX (CTChurchDBModule: db_insertfields/db_updatefields/db_deletefields) — the same non-REST legacy surface as the permission catalog, which this tool already treats as read-reference-only and never writes.
3. A declarative reconciler needs a clean REST create + item PUT/PATCH/DELETE; none exists, so promoting to a managed resource would mean faking writability through legacy admin AJAX — out of bounds. If CT later adds REST writes on /dbfields (the spec is self-trimming, so they'd appear silently), promote then. Full rationale: docs/field-definitions.md.

Testing

• Mocked-client only — never hits a live instance. New tests in tests/get-command.test.ts cover the unpaginated person-masterdata read and the auto-paginated data-fields read.
• npm test → 448 passed / 4 skipped (pre-existing integration skips); npm run typecheck and npm run lint clean.

Acceptance

• feat: manage person master-data field definitions + expose security levels (schema, not people) #47: person field schema + security levels readable via ct (person-masterdata + data-fields); writability decision recorded (read-only, with evidence). ✅
• feat: support custom field definitions (group custom fields; person custom fields) #48: custom group-field definitions readable via ct get data-fields (fieldCategory.table == "cdb_gruppe"); runbook updated. ✅ (read-only per the decision; no plan no-op because definitions are not REST-writable.)

Closes #47
Closes #48