[codex] fix stale group bindings when deleting via GroupService

[Soliyakeitong]

What changed

• route GroupService.Delete through DeleteCascade instead of the plain soft-delete path
• add a unit test proving GroupService.Delete must use cascade cleanup semantics

Why

We found two deletion paths for groups with different behavior:

• adminService.DeleteGroup already uses DeleteCascade
• GroupService.Delete only soft-deleted the groups row

That second path can leave stale account_groups bindings behind if any caller deletes a group through GroupService.Delete. In production, this presents as accounts still appearing bound to a deleted group, which breaks group counts and makes "ungrouped" filtering misleading.

Root cause

groupRepo.Delete only soft-deletes the group record, while groupRepo.DeleteCascade also clears dependent relations such as:

• account_groups
• API key group_id
• user_allowed_groups
• subscription rows for subscription-type groups

GroupService.Delete was calling the non-cascading repository method.

Validation

• go test -tags unit ./internal/service -run '^TestGroupService_Delete_UsesDeleteCascade$|^TestAdminService_DeleteGroup_'

Impact

This makes the non-admin delete service consistent with the admin delete path and prevents deleted groups from leaving orphaned account-group bindings behind.