Backport of 'Fix incorrect flow/agent settings when DAP is disabled'

What does this MR do and why?

Backport of !231963 (merged) to 18-9-stable-ee.

When DAP is disabled, its child settings (remote flows, foundational flows, foundational agents) were visually disabled in the UI but their form state remained stale, persisting incorrect true values downstream on save. This MR cascades child form state to false and emits the corresponding change events when DAP is toggled off.

Backport notes

The component layout in 18-9-stable-ee differs from master:

• ai_common_settings_form.vue still wraps the flow/agent children in <duo-agent-platform-settings-form>. The wrapper is preserved here; only the child availability bindings switch from the parent props (duoRemoteFlowsAvailability / duoFoundationalFlowsAvailability) to the parent's local data (flowEnabled / foundationalFlowsEnabled) so the cascade reactively re-renders the children.
• duo_foundational_agents_settings.vue does not pick up the new readOnly prop from master because the wrapper above already manages the disabled state. The enabled → foundationalAgentsEnabled prop rename and the data → computed setter refactor are kept (also applied in duo_flow_settings.vue).
• The master-only spec blocks ("disabled state for foundational agents and flow settings", DAP-checkbox-disabled tests, "data and privacy header and description") are omitted because that wiring is master-specific. The cascade-on-toggle spec block is kept since it exercises the actual fix.

References

• Original MR: !231963 (merged)
• Issue: #597245 (closed)

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• This MR is backporting a bug fix, documentation update, or spec fix, previously merged in the default branch.
• The MR that fixed the bug on the default branch has been deployed to GitLab.com (not applicable for documentation or spec changes).
• The MR title is descriptive (e.g. "Backport of 'title of default branch MR'"). This is important, since the title will be copied to the patch blog post.
• Required labels have been applied to this merge request
  • severity label and bug subtype labels (if applicable)
  • If this MR fixes a bug that affects customers, the customer label has been applied.
• This MR has been approved by a maintainer (only one approval is required).
• Ensure the e2e:test-on-omnibus-ee job has succeeded, or if it has failed, investigate the failures. If you determine the failures are unrelated, you may proceed. If you need assistance investigating, reach out to a Software Engineer in Test in #s_developer_experience.

Note to the merge request author and maintainer

If you have questions about the patch release process, please:

• Refer to the patch release runbook for engineers and maintainers for guidance.
• Ask questions on the #releases Slack channel (internal only).
• Once the backport has been merged, the commit changes will be automatically deployed to a release environment that can be used for manual validation. See after merging runbook for details.