bug(apply): group type changes plan as normal updates but require the grouptype migration endpoint

[bwl21]

Summary

ct plan currently treats a managed group's groupTypeId as a normal mutable field, but ct apply sends the change through the regular group update endpoint. ChurchTools rejects that request with HTTP 400 because changing a group's type requires the dedicated group-type migration endpoint and an explicit role mapping.

This means a plan can appear valid and executable, then fail partway through apply.

Reproduction

With ct-cli 0.1.0-mg.20260908.2+facfea6 and ChurchTools 3.137.0-RC7:

1. Create and manage a group using one group type.
2. Change the declaration so the same group key references another group type.
3. Run ct plan.
4. The plan reports a regular update from the old groupTypeId to the new one.
5. Run ct apply.

Observed failure:

POST /groups/273 failed (HTTP 400)
groupTypeId: validation.always.invalid

The concrete response says that groupTypeId is never valid on the regular group update payload.

ChurchTools-supported operation

The ChurchTools web client performs this migration through:

POST /groups/{groupId}/grouptype

with a payload containing:

{
  "groupTypeId": 21,
  "roleMapping": {}
}

The UI asks the user to map every role of the old group type to a role of the new group type before submitting the operation.

Expected behavior

ct plan should recognize a group-type change as a special migration rather than a normal group-field update.

One of these safe behaviors should be implemented:

1. Support the migration end-to-end:

   • model an explicit role mapping in config;
   • show the old and new group type plus the proposed role mapping in the plan;
   • refuse ambiguous or incomplete mappings at plan time;
   • call POST /groups/{id}/grouptype during apply;
   • persist the new snapshot and converge to No changes.

2. Until migration support exists, mark a groupTypeId change as incomplete/non-applicable during ct plan with guidance to use the ChurchTools UI or recreate the group.

The current behavior should not emit an apparently applicable plan that is guaranteed to fail during apply.

Safety considerations

• Never infer a role mapping when multiple target roles are possible.
• Plans should clearly distinguish this migration from an ordinary field update.
• Existing memberships and role assignments must not be silently dropped.
• A mid-apply failure must continue to preserve resumable state, as it does today.