Expose automatic_rebase_enabled on project read endpoints

Release notes

The automatic_rebase_enabled project setting can be written through the REST API but never read back. Exposing it on project read endpoints would let API clients and infrastructure-as-code tools verify and reconcile the setting instead of writing to it blind.

Problem to solve

automatic_rebase_enabled was added to the projects API in !250632 (merged) (GitLab 19.4). It is accepted only by PUT /projects/:id:

• POST /projects ignores it — spec/requests/api/projects_spec.rb: it 'ignores the edit-only automatic_rebase_enabled parameter'
• No read endpoint returns it. It is not exposed in lib/api/entities/project.rb, and the update spec asserts expect(json_response).not_to have_key('automatic_rebase_enabled').
• There is no GraphQL equivalent on ProjectType or ProjectSettingType.

Consequences for API consumers:

1. No verification. After a PUT there is no way to confirm the value took effect, or to read the current value of a project you did not just write.
2. No reconciliation. Configuration-management tools cannot detect that someone changed the setting in the UI. For the Terraform provider specifically this means the attribute cannot be imported and drift is invisible — see terraform-provider-gitlab#6883.
3. Inconsistency. Every comparable merge-request setting on the same resource (merge_method, squash_option, remove_source_branch_after_merge, only_allow_merge_if_pipeline_succeeds, …) round-trips. This one is the exception, which is surprising rather than intentional-looking.

Proposal

Expose the attribute on project reads, alongside the settings it belongs with:

# lib/api/entities/project.rb, near merge_method / squash_option
expose :automatic_rebase_enabled, documentation: { type: 'Boolean' }

That makes GET /projects/:id, GET /projects, and the PUT response all return it, and the attribute round-trips like its neighbours. Optionally also expose it in GraphQL for parity.

Accepting it on POST /projects would be a further nice-to-have, so a project can be created with the setting in one call, but the read path is the blocking gap.

Intended users

• Sasha (Software Developer)
• Priyanka (Platform Engineer)
• Sidney (Systems Administrator)

Permissions and Security

No new permissions. The attribute would be exposed under the same conditions as the merge settings already returned by the project entity.

Documentation

doc/api/projects.md — add automatic_rebase_enabled to the response attribute tables for "Get single project" and "List all projects", and note the version it became readable.