feat: group ↔ campus assignment + deliberate group field coverage #21

Groups currently cannot be assigned to a campus — campusId appears nowhere in src/, and a group's managed fields are only name, groupTypeId, groupStatusId (src/resources/registry.ts). For a Campus Management tool whose core blueprint is "instantiate this area per campus", the campus link is a first-class requirement. Part of the Phase 6 epic; pairs with the logical-reference resolver (campus referenced by key, not id).

Scope

• Add campusId to the group's managedFields + DSL (campus: "mainz" via resolver, numeric escape hatch). Verify live where CT carries it on the group body (information.campusId) and that PATCH accepts it.
• Deliberate field audit: go through the group PATCH body / live group object and decide per field: managed, opt-in synthetic, or explicitly out of scope. Candidates seen live: visibility, note, autoAccept/open-for-members settings, chat status, sort key. Output = a short decision table in the docs, not necessarily more fields.
• State snapshot migration: existing adopted groups have snapshots without the new fields — extending managedFields must not produce phantom drift or broken PUT/PATCH bodies (same failure class as Phase 4 follow-ups: destroy ordering/protection, field-rename migration, backup fidelity, cleanups #17's shortName→shorty item; solve both with one migration mechanism, or explicitly sequence after it).
• Re-adopt guidance (or automatic snapshot refresh) documented.

Acceptance criteria

• A blueprint can create a group assigned to its campus; ct plan shows a campus move as a normal field update.
• Adopting an existing campus-assigned group captures the campus; re-running plan is a no-op.
• Pre-existing state files (snapshots without the new fields) neither drift forever nor break updates — covered by a test.
• Field decision table committed under docs/.