Bug: deleted COS left as zimbraCOSId; mailbox service keeps serving the old COS values while LDAP falls back to default

Summary

After a Class of Service is deleted, accounts that still reference it keep the dangling zimbraCOSId. LDAP-side lookups fall back to the default COS, but the mailbox service keeps serving the old COS's values from its account cache, so the two views of the same account disagree until the account cache is flushed.

What we saw

• About 190 accounts on one server had zimbraCOSId set to three COS ids that no longer existed (carbonio prov gac listed only default and defaultExternal; no domain default COS).
• carbonio prov mc default zimbraFeatureMailSendLaterEnabled TRUE, then:
  • carbonio prov -l ga user@example.com zimbraFeatureMailSendLaterEnabled returns TRUE (LDAP, falls back to default)
  • carbonio prov ga user@example.com zimbraFeatureMailSendLaterEnabled returns FALSE (mailbox service)
  • carbonio prov fc -a cos did not change the second result.
• carbonio prov mc <dangling-cos-id> ... gives ERROR: account.NO_SUCH_COS.
• Only carbonio prov fc account made the mailbox service return TRUE. Accounts that were not in the cache already returned TRUE.

Expected: either deleting a COS that accounts still reference is refused (or the accounts are moved to the domain/global default), or the mailbox service resolves a missing COS the same way as the LDAP lookup and a COS change/flush reaches it.

Steps to reproduce

1. Create COS tmp, assign it to an account, log in to that account (so it is cached).
2. Delete COS tmp (the account keeps zimbraCOSId = the deleted id).
3. Change an attribute on default, e.g. zimbraFeatureMailSendLaterEnabled TRUE, and prov fc -a cos.
4. Compare prov -l ga <account> <attr> with prov ga <account> <attr>.

Environment: Carbonio CE 25.x (4.25.2_ZEXTRAS_202603), Ubuntu 24.04, single server, 307 mailboxes. How the COSes came to be deleted is not known (older admin action).

Also filed on GitHub: https://github.com/zextras/carbonio-mailbox/issues/1172