Expose automatic_rebase_enabled in project update API

PUT /projects/:id now accepts automatic_rebase_enabled, so API consumers can turn server-side automatic rebase before merge on and off. The setting already existed in the project merge request settings UI, but had no REST surface. It is write-only: not returned in any response, and ignored on POST /projects and POST /projects/user/:user_id, matching how other single-project settings like reviewer_assignment_strategy behave.

Detailed context for AI agents

What this does

Exposes the existing automatic_rebase_enabled project setting (boolean column on project_settings, default false) as a write-only request parameter on PUT /projects/:id. The setting is already in the project merge request settings UI as the "Enable automatic rebase prior to merge" checkbox. When the project's merge method is fast-forward, or merge commit with semi-linear history, and the source branch is behind target, GitLab rebases the source branch server-side at merge time instead of requiring the user to click Rebase and wait. Server-side rebase strips GPG commit signatures, which is why the setting is togglable. Related epic: Rebase and Merge with One Click - the feature already shipped, this MR only adds the missing REST write surface for it.

Why edit-only

The param is declared in optional_update_params_ce (and added to update_params_at_least_one_of) in lib/api/helpers/projects_helpers.rb, so it is only settable via PUT /projects/:id and is silently ignored on the create endpoints. A spec asserts that ignore-on-create behavior. This follows recent project settings additions - reviewer_assignment_strategy (!238474 (merged)), web_based_commit_signing_enabled (!194650 (merged)), and the duo_* settings. These are merge and workflow settings that only have meaning against an existing project and its merge method, so they are configured after creation.

Why there is no response field

An earlier revision of this MR also exposed the value on GET /projects/:id and in the POST/PUT responses. That required a new API entity concern plus two new leaf entity classes inheriting the WithCatalogSetting / WithAccessAndCatalogSetting chain, because the field cannot be added to the high-impact Entities::Project entity without editing api_entity_exposure_baseline.yml (guarded by the API/EntityExposureGrowth cop). That scaffolding was disproportionate to the ask, so it was dropped: three new files were deleted and all six entity references in lib/api/projects.rb were reverted. No API entity class is touched by this MR.

Read support can be added later as its own change if API consumers need it, ideally with an API Platform opinion on entity naming first, since a leaf entity per field conflicts with the styleguide rule that entities are named for domain context rather than for the single field they add.

Param flow

PUT /projects/:id param -> declared_params -> Projects::UpdateService -> new delegated setter Project#automatic_rebase_enabled= (delegates to project_setting in app/models/project.rb) -> persisted through the project_setting autosave association.

Files touched (5)

• app/models/project.rb - delegates automatic_rebase_enabled and automatic_rebase_enabled= to project_setting.
• lib/api/helpers/projects_helpers.rb - adds the optional Grape param to optional_update_params_ce and to update_params_at_least_one_of.
• doc/api/projects.md - request attribute row and version history note, in the "Update a project" section only.
• doc/api/openapi/openapi_v3.yaml - regenerated via gitlab:openapi:v3:generate. The v2 generate task is currently broken on master (Oj::Parser::TotalElementsError), unrelated to this change, so the v2 file is untouched.
• spec/requests/api/projects_spec.rb - one spec asserting POST /projects ignores the parameter, one asserting PUT /projects/:id persists it.

Verification

Both new specs pass locally. RuboCop is clean on the three changed Ruby files. Earlier manual testing against a local GDK instance confirmed PUT toggles and persists the setting, and that invalid values return 400.

Not in scope

• GraphQL exposure - no GraphQL field exists for this setting today (#519390 (closed) proposed one, not implemented).
• Reading the value over REST, per the entity rationale above.

Rollout

No feature flag, the underlying setting has none. Targeting GitLab 19.3. Changelog entry via the Changelog: added commit trailer.