Disk encryption: support custom filevault/escrow configurations

[melpike]

Goal

User story
As an IT admin,
I want to be able to customize filevault and escrow configurations separately
so that I can use a custom setup (ie, use Xcreds to handle FileVault, but still have Fleet handle escrow).

Related to community PR

Changes

Product

• UI changes: Figma
• CLI (fleetctl) usage changes: fleetctl apply will need to accept per-platform disk encryption settings
• YAML changes:
  • [YAML] Change escrow_disk_encryption_key to enable_escrow_disk_encryption_key #51191
  • [YAML] Add 'escrow_disk_encryption_key_only' configuration #50232
  • Depreciating the top level enable_disk_encryption in favor of per-platform settings
• REST API changes:
  • [API] Revise disk encryption settings in API documentation #51190
  • [API] Add enable_disk_encryption and enable_escrow_disk_encryption_key parameter #50235
  • Depreciating the top level enable_disk_encryption in favor of per-platform settings
• Fleet's agent (fleetd) changes:
  • For macOS: Escrow Buddy's install condition changes from "disk encryption enforced" to "Escrow recovery key with Fleet" specifically — independent of whether Enforce is checked.
• Fleet server configuration changes: No changes
• Exposed, public API endpoint changes: No changes
• fleetdm.com changes:
  • Update the "Enforce disk encryption" guide and YAML/API reference docs to describe new per-platform disk encryption settings.
  • Deprecation of the old top-level enable_disk_encryption key should be documented
• GitOps mode UI changes: New checkbox disabled in gitops mode
• GitOps generation changes: fleetctl generate-gitops needs to output the new key alongside the existing one.
• Activity changes: [Activity] Document escrow disk encryption key activities #50236
• Permissions changes: No changes — same permissions as existing disk encryption toggle (team admin+, global admin)
• Changes to paid features or tiers: Fleet Premium
• My device and fleetdm.com/better changes: No changes
• Usage statistics: No changes
• Other reference documentation changes:
  • [Docs] Revise disk encryption enforcement details #50238
  • [Route] Add route for Linux disk encryption guide #50191
• First draft of test plan added
• Once shipped, requester has been notified
• Once shipped, dogfooding issue has been filed

Engineering

Implementation notes:

1. Fleet will still only ever create one disk encryption related profile, always with the same Payload Identifier, etc, per-team. Difference is that if escrow only is enabled, only the escrow bits will be in it, and if encryption is enabled, they won't. The migration case is that an existing fleet with disk encryption enabled gets encryption + escrow turned on and the profile remains byte-identical
2. The old setting stays around as a "virtual" rollup of "are all the disk encryption options enabled". When set to true it enables them all for each platform
3. Behavior on windows and Linux hosts does not change at all - only on mac which may now have escrow enabled without any profile actually enforcing Filevault, or Filevault enabled without anything actually enforcing escrowing of keys
4. The existing custom filevault configuration option would need to be used for a customer who wants a disk encryption profile + fleet handling escrow(so sending the existing profile with only the escrow bits
5. A prior migration edited existing filevault profiles in-place. Be careful not to go writing new profiles in the migration case - no profile should be created or changed until a user actually does an action to change settings
6. As of time of speccing a few comments are outstanding on the docs. Please carefully read them before starting work to understand assumptions made and what may change
7. It may be worth reading Apple's schemas and docs around the payloads to familiarize yourself

• Test plan is finalized
• Contributor API changes: TODO
• Feature guide changes: Guide changes already made(see above product section)
• Database schema migrations: See subtasks

ℹ️  Please read this issue carefully and understand it. Pay special attention to UI wireframes, especially "dev notes".

Risk assessment

• Risk level: Low

Test plan

Make sure to go through the list and consider all events that might be related to this story, so we catch edge cases earlier.

Core flow

macOS

• All four combinations of "Turn on disk encryption" / "Escrow recovery key with Fleet" work via UI, fleetctl apply, and API.
• Escrow Buddy installs based solely on the Escrow setting. Does not install on a host where Escrow was never turned on on its team
• FileVault-enable profile is pushed, or not, based solely on the Enforce setting.
• Existing enable_disk_encryption: true configs migrate with both Enforce and Escrow checked.
• Third-party-encrypted host (Enforce ✗ / Escrow ✓ and filevault turned on by separate uploaded profile OR manual turn-on) gets key escrowed without Fleet pushing an enable profile.
• Key rotation re-escrows when Escrow is checked and host does a "sudo profiles renew" or an existing, encrypted host unenrolls and re-enrolls(or just enrolls for the first time post-encryption).
• No conflict when escrow-only profile is combined with a custom FileVault profile (mdm.enable_custom_filevault).
• Enforce ✓ / Escrow ✓ behaves identically to today's single-checkbox flow.

Windows

• "Turn on disk encryption" and "Require BitLocker PIN" work via UI, fleetctl apply, and API.
• "Require BitLocker PIN" disabled in UI when encryption is off.
• Existing configs migrate correctly.

Linux

• "Escrow recovery key with Fleet" works via UI, fleetctl apply, and API.
• Fleet Desktop prompts for LUKS key escrow; no enforcement profile is sent.
• Key rotation is detected and re-escrowed.

Cross-platform

• fleetctl get config / generate-gitops round-trips all per-platform settings.
• Deprecated enable_disk_encryption accepted in YAML but not emitted by generate-gitops.
• GitOps mode disables all checkboxes.
• Disk encryption status table correct for all platforms.

Gitops

• Gitops operates properly with old key(sets all values to true)
• Gitops operates properly with new keys
• Gitops generates emits only the new keys

Edge cases

• TODO

Supplemental testing

Testing notes

Confirmation

1. Engineer: Added comment to user story confirming successful completion of test plan (include any special setup, test data, or configuration used during development/testing if applicable).
2. QA: Added comment to user story confirming successful completion of test plan.
3. QA: Determined whether this story needs Playwright automation.
   • Needs automation: Yes / No
   • If yes, filed a follow-up issue in the :help-qa project with status "Needs automation":