Add Observability provisioner instance settings columns

What does this MR do and why?

Adds two instance settings for the GitLab Observability provisioner, which creates per-tenant Observability backends on GitLab.com:

• o11y_settings: a jsonb column holding o11y_provisioner_url, with a JSON schema and a hash check constraint.
• o11y_provisioner_api_key: a jsonb column encrypted with encrypts, following the sdrs_jwt_signing_key pattern.

The provisioning client currently uses a hardcoded endpoint and key. Moving them into instance settings lets them be configured and rotated, and left unset on instances that don't provision Observability tenants. Nothing reads these columns yet.

This is the first of three MRs:

1. Columns and model (this MR)
2. Settings API: !262322 (merged)
3. Client reads the settings: !262323 (merged)

Design notes

• The legacy observability_settings column belongs to the old GitLab Observability Backend and is not reused. Its check constraint is already named check_application_settings_o11y_settings_is_hash, so the new one is check_application_settings_current_o11y_settings_is_hash.
• The URL must use https. Gitlab::HTTP still blocks local addresses when the request is made.
• The key is capped at 510 characters, and the JSON schema validations have a size_limit.
• encrypts puts the key in ApplicationSetting.sensitive_attributes, so audit events and serialization omit it. A spec covers this.
• application_settings has one row, so the check constraint validates immediately.
• The API key gets its own column rather than a key inside o11y_settings, because encrypts works on whole columns and can't encrypt one key inside a jsonb_accessor hash.
• Both columns are added to GITLAB_COM_DIFFERENT_THAN_DEFAULT in scripts/cells/application-settings-analysis.rb. GitLab.com sets them, so regenerating the cells analysis keeps gitlab_com_different_than_default: true.

References

• Related issue: https://gitlab.com/gitlab-org/gitlab/-/work_items/633458

Screenshots or screen recordings

Not applicable, no UI changes.

How to set up and validate locally

1. Run bin/rails db:migrate.

2. In the Rails console:

   s = ApplicationSetting.current
   s.update!(o11y_provisioner_url: 'https://provisioner.example.com/api/v1/provision_requests', o11y_provisioner_api_key: 'example')
   s.o11y_settings              # => {"o11y_provisioner_url"=>"https://provisioner.example.com/..."}
   s.update(o11y_provisioner_url: 'http://insecure.example.com') # => false
   ApplicationSetting.connection.select_value("SELECT o11y_provisioner_api_key FROM application_settings") # encrypted

Migration output

main: == 20261014233244 AddO11ySettingsToApplicationSettings: migrating =============
main: == 20261014233244 AddO11ySettingsToApplicationSettings: migrated (0.5101s) ====

main: == 20261014233244 AddO11ySettingsToApplicationSettings: reverting =============
main: == 20261014233244 AddO11ySettingsToApplicationSettings: reverted (0.5321s) ====

Rollback

The down method drops both columns and the check constraint. Nothing reads these columns yet, so a rollback loses only the configured provisioner URL and API key.

Database testing

db:gitlabcom-database-testing is red because a commit status update failed after the job started the downstream pipeline. That pipeline ran and posted results for 6747fc68: no warnings, 6–7 seconds on each database.

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.

A maintainer other than the author merges this MR.