Draft: Remove early_access_studio_participant from user_preferences

What does this MR do and why?

This removes user_preferences.early_access_studio_participant, a column added for the Project Studio early access rollout, which has ended. !261235 (merged) ignored it in UserPreference in 19.6 and removed the last code that read it.

This is step 2 of 3 for the 19.7 milestone, following Dropping columns: a post-deployment migration one release after the ignore rule. Step 1 ignored the column in 19.6, so this must merge only once master is on 19.7, after the 19.6 stable branch is cut. The migration's down adds the column back as boolean, default false, not null. The column has no index, constraint or view, so a transactional remove_column is enough. Step 3 removes the rule in 19.8, after 2026-12-17. If this slips to 19.8, I'll bump the rule's remove_with and remove_after here first.

Dropping the column deletes its value in every row of user_preferences. Nothing has read it since 19.6, so users see no change. After a rollback every row reads false, so the rows the early access rollout set to true on GitLab.com could only come back from a backup. I can't set the data-deletion label: could a reviewer add it?

Rolling back adds the column at the end of the table, so the rollback check of db:check-migrations will report a db/structure.sql difference. On the same step for use_work_items_view, a database maintainer applied pipeline:skip-check-migrations for that position change: !256131 (merged)

References

Related to #578235 as step 2 of 3, so it does not close the issue.

• Step 1, merged for 19.6: !261235 (merged)

Screenshots or screen recordings

No UI change.

How to set up and validate locally

1. Run bin/rails db:migrate. In a Rails console, ApplicationRecord.connection.column_exists?(:user_preferences, :early_access_studio_participant) returns false, and UserPreference.new.valid? runs without raising.
2. Run bin/rails db:migrate:down:main with VERSION set to the timestamp in the migration's filename. The same call returns true, and \d user_preferences in gdk psql shows the column as boolean, not null, default false, last in the table.
3. Run bin/rails db:migrate again. git status is clean.

What I ran locally

The migration, db/structure.sql and the version file are what bin/rails db:migrate wrote on a database loaded from master's schema.

Check	master	This branch
column_exists? after db:migrate	true	false
After db:migrate:down		the column is back as boolean DEFAULT false NOT NULL, last in the table
db:migrate again		db/structure.sql and the version file are byte for byte the first run's

There is no committed migration spec: the migration testing guide does not enforce one on a post-deployment migration that only changes the schema. A local one with reversible_migration fails without the migration, with an up that does nothing, and with a down that adds the column back nullable and without a default, and passes with this migration.

scripts/validate_migration_timestamps, scripts/validate_migration_checksum and scripts/post_deployment_migrations_validator pass. scripts/validate_migration_schema stops at the rollback check with the column moved to the end of the table, and nothing else.

spec/models/user_preference_spec.rb, the delegations and ensure user preference blocks of spec/models/user_spec.rb, spec/graphql/types/user_preferences_type_spec.rb, spec/requests/api/graphql/mutations/user_preferences/update_spec.rb, spec/lib/gitlab/database/obsolete_ignored_columns_spec.rb and the user_preferences examples of spec/db/schema_spec.rb pass on this branch. RuboCop reports no offenses on the migration, and both commit message linters pass.

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.