Fix FileVault key escrow on ADE-enrolled Macs (#45928)

After ADE enrollment with enable_disk_encryption: true, hosts reported
as unencrypted with the disk-encryption policy failing and no recovery
key escrowed until the user logged out/in or restarted.

## Root cause
Fleet's shared macOS disk-encryption probe was:

```
SELECT 1 FROM disk_encryption
WHERE user_uuid IS NOT "" AND filevault_status = 'on' LIMIT 1
```

On the osquery disk_encryption table, filevault_status and user_uuid
are populated from independent sources: filevault_status from
`fdesetup status`, user_uuid from `diskutil apfs listCryptoUsers`
(the UUID of a user with SecureToken authority to unlock the volume).

In the post-ADE window, even with ForceEnableInSetupAssistant=true,
SecureToken propagation can lag — filevault_status='on' but
user_uuid='' for a brief period that resolves on a session event.
When the predicate failed, the query returned 0 rows and three
downstream behaviors broke in lockstep:

  - host_disks.encrypted flipped to false ("unencrypted")
  - the built-in "Full disk encryption enabled (macOS)" policy failed
  - mdm_disk_encryption_key_file_*_darwin returned encrypted=0,
    gating the PRK ingest and leaving the recovery key un-escrowed

The predicate originated in groob's standard query library entry
from 2021 as a strict compliance check ("is the host actually
protected, with a user able to unlock it?"). When the disk-encryption
status feature shipped in Nov 2022 (PR #8526, issue #3906), the
same string was reused verbatim and later extracted into
usesMacOSDiskEncryptionQuery — never revisited for whether the
SecureToken gate made sense outside the compliance-policy context.

**Related issue:** Resolves #45369

changes/45369-ade-filevault-query

@@ -0,0 +1 @@
+- Fixed issue where ADE-enrolled macOS didn't report filevault until restarted