feat: add read-only permission reports #142

Problem

ChurchTools permissions span person, person-status, group-type-role, and concrete group-role domains. There is no single read-only view that answers either of these operational questions:

• Which complete permission set does each subject currently have?
• Which subjects currently hold each permission?

Existing instance-specific reporting scripts should not have to reimplement collection, normalization, and grouping outside ct-cli.

Proposed CLI

Add read-only permission reports:

ct report permissions --by-subject [file]
ct report permissions --by-object [file]
ct report permissions --by-both <base>

Both orientations should be rendered from one authenticated collection pass. Reports may contain instance-specific labels and person names, so generated output must not be committed accidentally.

Scope and safety

• Read permissions only; do not change adopt grants, plan, or apply semantics.
• Preserve non-declarable permission dimensions and direct person grants in reporting without managing people.
• Retain ChurchTools labels losslessly, including significant whitespace.
• Produce deterministic grouping and ordering suitable for comparison and audits.
• Keep generated report files out of version control by default.

Legacy parity

• Subjects with identical complete permission sets share one deterministic fingerprint section.
• Preserve the historical empty-set fingerprint where compatibility requires it.
• Include empty status and group-type-role subjects.
• Include person and concrete group-role subjects only when they have direct permissions, matching the existing report behavior.
• Preserve object labels and subject/object assignment rows; PHP-specific implementation details need not be reproduced.

Acceptance criteria

• Subject- and object-oriented Markdown reports are available from the CLI.
• --by-both collects live data once and writes both reports.
• Representative person, status, group-type-role, and group-role domains are covered by tests.
• Deterministic fingerprints, empty sets, label preservation, and ordering are tested.
• Commands are read-only and do not alter adoption semantics.
• Documentation explains usage and the sensitivity of generated output.
• Build, typecheck, lint, unit tests, and a guarded live read-only smoke test pass.

Implementation is proposed in #133.