acllist: reject a new record with no applicable content

[requilence]

What

ACL permission checks run inside the per-content-type apply handlers. A record whose content reaches none of them was applied without any check on its author:

• a content value with the oneof unset, or of a type this build does not know, fell through applyChangeContent's default and returned nil;
• an AclData with no content values (empty Data, or only unknown fields) looped zero times;
• a permissionChanges value with no changes reached its handler, which checks the author per change, so it checked nothing.

The existing ErrEmptyAclRecordData guard never runs on live paths: both Unmarshall and UnmarshallWithId always set Model.

Fix

Reject both cases at admission only: ValidateRawRecord (used by the coordinator before handing a record to consensus) and the record builder's preflight. Both now use a dedicated admission validator.

Everything that replays records already in the log stays lenient, whatever the verifier:

• BuildAclListWithIdentity (clients, and node stats / anytype-heart paths that build with ValidateFull)
• storage migration (aclmigrator re-adds records via AddRawRecords with ValidateFull)
• sync ingest (AddRawRecord)

A record already in the log was accepted by the network, and a content type added in a later release reaches old clients the same way, so failing there would stop the ACL at that record.

Compatibility

• Existing ACLs containing such records keep building, migrating and syncing (covered by tests for both verifiers).
• BuildBatchRequest with an empty payload now fails locally with ErrNoAclContent instead of sending an empty record. RevokeAllInvites therefore returns early when there is nothing to revoke (it previously sent an empty record), so a retry after the revocation already landed still succeeds. Likewise ChangePermissions with no changes (anytype-heart drops changes a member already has, so a retried change can arrive empty) returns without sending.
• A new content type must reach the coordinator before clients start sending it (already the required deploy order, since the coordinator validates content).

Tests

• TestAclList_ValidateRawRecordRejectsNoApplicableContent: all four shapes rejected at admission.
• TestAclList_StoredNoApplicableContentStillBuilds: the same shapes, once stored, still ingest, rebuild, accept new owner records on top, and migrate into a fresh list, under validating and non-validating verifiers.
• TestAclList_ValidateRawRecordRejectsMixedContent: a valid change does not carry an inapplicable one past admission in either order, and afterValid never runs.
• TestAclRecordBuilder_EmptyBatchRequest, TestAclSpaceClient_RevokeAllInvites, TestAclSpaceClient_ChangePermissionsWithoutChanges.

go test ./... passes.

Linear: GO-7544

[github-actions]

New Coverage	62.0% of statements
Patch Coverage	100.0% of changed statements (32/32)

---

^{Coverage provided by https://github.com/seriousben/go-patch-cover-action}