Remove migrated AI infrastructure columns from ai_settings

What does this MR do and why?

Drops five AI infrastructure columns from ai_settings. Their data moved to application_settings in 19.2 (restore fix in 19.3), and nothing reads them from ai_settings anymore.

• ai_gateway_url
• ai_gateway_timeout_seconds
• enabled_instance_verbose_ai_logs
• duo_agent_platform_service_url
• self_hosted_duo_agent_platform_service_secure

The post-deployment migration also drops the two text-length checks. down restores the columns and checks. Ai::Setting#ignore_columns now uses remove_with: '19.6', so the ignore rule is removed in the next release.

No migration spec: it's a schema-only post migration, which the testing guide exempts.

Data deletion: no data is lost. The values in these columns were already saved in application_settings (copied in 19.2, restored in 19.3), which is where the app reads them from. ai_settings is a single-row table, so only that one row is affected.

References

• Related to #607621 (closed)

Screenshots or screen recordings

Not applicable: database-only change, no UI.

How to set up and validate locally

1. Run the migration:

   bin/rails db:migrate

2. In the Rails console, check the columns are gone:

   cols = %w[ai_gateway_url ai_gateway_timeout_seconds enabled_instance_verbose_ai_logs duo_agent_platform_service_url self_hosted_duo_agent_platform_service_secure]
   cols.map { |c| ApplicationRecord.connection.column_exists?(:ai_settings, c) }
   # => [false, false, false, false, false]

3. Roll back, then rerun the console check. It now returns all true:

   bin/rails db:migrate:down:main VERSION=20260930091742

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.