Override local apps settings with requirements.toml settings

[canvrno-oai]

This PR changes app and connector enablement when requirements.toml is present locally or via remote configuration.

For apps.* entries:

• enabled = false in requirements.toml overrides the user’s local config.toml and forces the app to be disabled.
• enabled = true in requirements.toml does not re-enable an app the user has disabled in config.toml.

This behavior applies whether or not the user has an explicit entry for that app in config.toml. It also applies to cloud-managed policies and configurations when the admin sets the override through requirements.toml.

Scenarios tested and verified:

• Remote managed, user config (present) override

  • Admin-defined policies & configurations include a connector override:
    [apps.<appID>] enabled = false
  • User's config.toml has the same connector configured with enabled = true
  • TUI/App should show connector as disabled
  • Connector should be unavailable for use in the composer

• Remote managed, user config (absent) override

  • Admin-defined policies & configurations include a connector override:
    [apps.<appID>] enabled = false
  • User's config.toml has no entry for the the same connector
  • TUI/App should show connector as disabled
  • Connector should be unavailable for use in the composer

• Locally managed, user config (present) override

  • Local requirements.toml includes a connector override:
    [apps.<appID>] enabled = false
  • User's config.toml has the same connector configured with enabled = true
  • TUI/App should show connector as disabled
  • Connector should be unavailable for use in the composer

• Locally managed, user config (absent) override

  • Local requirements.toml includes a connector override:
    [apps.<appID>] enabled = false
  • User's config.toml has no entry for the the same connector
  • TUI/App should show connector as disabled
  • Connector should be unavailable for use in the composer

[mzeng-openai]

merge_unset_fields treats the new apps table as a single all-or-nothing field. Once a higher-precedence layer has any apps entry, lower-precedence layers can no longer add independent app disables; even an empty higher-priority apps table blocks lower layers entirely.

[canvrno-oai]

Good catch, thanks! I've added merge_enablement_settings_descending (and tests), which for now is only for AppsRequirementsToml but could be abstracted out to other enablement settings in the future. This will ensure that we process enabled settings in descending order, giving preference to any false values from any managed sources. It will not enable any downstream configs, only disable them.

[canvrno-oai]

/merge