Managed settings: reworked choice of MDM, WSL and fallback sources

What

Managed settings are policies set by an organisation. They can come from several sources, such as a remote server, MDM (device-management profiles on macOS or Windows), or a file on disk, and Claude Code picks among them in order. This release changes how that choice works:

• An MDM document now counts as present when it holds any policy content; before, its parsed settings had to be non-empty.
• User-writable plist files (macOS settings files) are skipped once a machine-level source has loaded.
• Load failures are now tracked as a loadState.
• On WSL (Linux running inside Windows), wslInheritsWindowsSettings now has three states: armed, disarmed and unreadable. A quoted true or false is accepted with a warning. An invalid value, or a flag file that cannot be read, fails closed: the source is treated as holding policy and an error is added.
• On WSL, the Linux managed-settings file (including managed-settings.d) is skipped when the MDM or Windows policy source holds policy or failed to load and you have not turned inheritance on. With inheritance on, the Windows chain is used if either it or MDM holds policy.
• When the remote or MDM source holds only values that could not be applied as written, the next source down now supplies the managed settings. The unusable source's fail-closed reading still applies alongside it, the most restrictive value of each key wins, and a status-only warning is shown. Before, the highest source that was present won even if nothing in it could be used.
• The merge result gains tierSources, parentNeverShutOut, parentIncluded and heldEmpty, and availableModels is no longer set as its own key on the parent slice; the admin slot is spread into it instead.

Why

A broken or unreadable policy source no longer silently falls through to user settings, and a malformed remote or MDM policy no longer blanks out valid policy from the next source. Admins get both, combined in the most restrictive way.