feat(adopt): bulk/filtered adoption, --with-dynamic ruleset capture, unknown-field warnings

[2000game]

Summary

Implements #51 — three related asks:

1. Bulk/filtered group adoption — ct adopt group is now a dedicated subcommand supporting:

• ct adopt group <id> <id> <id> — multiple positional ids in one invocation.
• ct adopt group --type <groupTypeIdOrKey> — adopt every group of a group type (numeric id or logical key resolved against the live /group/grouptypes catalog). Uses client.getAll for listing (bug(get): list commands return only ChurchTools first page; raw errors hide status/body #50).
• ct adopt group --children-of <idOrKey> — recursively adopt a group's full hierarchy subtree via /groups/{id}/children, parent-before-child, excluding the root; guarded against a cyclic hierarchy with a visited-id set.
• Selection filters are mutually exclusive (exactly one of: ids / --type / --children-of); duplicate resolved ids are deduped; --key is rejected once more than one group resolves.
• Bulk output stays per-resource (state entries + individual config snippets), plus one grouped // group-headed config block for pasting. configSnippet's own per-line FORMAT is untouched (feat(dx): human-authorable configs — idiomatic adopt output, dynamic sugar, located errors, machine-only state, blueprints by default #52 reworks that later).

2. --with-dynamic ruleset capture — for each adopted group (single or bulk) that IS a dynamic group (a 404 on the ruleset GET means "not dynamic" — skipped silently), captures its normalized ruleset (reusing engine/dynamic.js's normalizeRuleset, the same normalizer plan/apply already use) to rulesets/<key>.json and emits the dynamic: { status, ruleset: { ref } } block in the printed config snippet — so ct plan is a no-op once pasted. Covered end-to-end via buildPlan against the same mocked client (see acceptance test below).

3. Unknown-declaration-field warning — the config DSL (src/config/context.ts) now warns (via the existing warn() UI helper, never throws) when a declaration carries a field the registry doesn't manage for that type, e.g. campus's vestigial shortName instead of the real shorty. The allowlist is derived from the registry's own managedFields (a new knownFields() export) — never hand-copied, so it can't drift. File:line locations are #52's job, not built here.

Bonus fix: while building the group subcommand I found that Commander does not merge a same-named parent+subcommand option into either level's plain .opts() — ct adopt's parent already declares -s/--state/-e/--env, and any subcommand redeclaring them (both grants and the new group) silently had those flags dropped. Fixed by reading command.optsWithGlobals() instead, with a regression test on adopt grants proving --state is now actually honoured.

Test plan

• npm test — 435 passed, 4 skipped (live-only), 0 failed
• npm run typecheck — clean
• npm run lint — clean
• New tests/adopt-group-command.test.ts (20 tests): multi-id list, --type (numeric + logical key), --children-of (nested subtree, cycle guard, state-key resolution, empty subtree), --with-dynamic (capture, skip-silently for non-dynamic, dry-run previews without writing, mixed bulk selection), and an end-to-end acceptance test reconstructing the pasted config from the printed snippet and asserting buildPlan returns an all-no-op plan.
• tests/registry.test.ts / tests/context.test.ts: knownFields() allowlist derivation + unknown-field warning (including the exact shortName vestigial-field scenario from the issue).
• tests/adopt-grants-command.test.ts: regression test for the optsWithGlobals() fix.
• Never hits a live instance — every test uses a mocked/fake CtClient.

Closes #51