Merge the SqlRequestSettings endpoints into one domain resource

[PrestaEdit]

Questions	Answers
Branch?	dev
Description?	Consolidates the two pending SqlRequestSettings Admin API PRs into a single domain resource, with a read/write symmetric endpoint and API-only integration tests
Type?	new feature
BC breaks?	no
Deprecations?	no
Fixed ticket?	Related to PrestaShop/PrestaShop#39630
How to test?	See below
Sponsor company	PrestaEdit

What this PR does

Merges #280 (PUT /sql-request-settings) and #335 (GET /sql-request-settings) into one PR, then reworks the resource and the tests as a whole, following the mutualisation done on the Product domain in #410.

Endpoints

Method	URI	CQRS	Scope
GET	/sql-request-settings	GetSqlRequestSettings	sql_management_read
PUT	/sql-request-settings	SaveSqlRequestSettingsCommand + GetSqlRequestSettings	sql_management_write

Design decisions

• One resource class: SqlRequestSettings replaces the SqlRequestSettings / SqlRequestSettingsRead pair from the two source PRs. Both declared the exact same two properties.
• Read/write symmetry: the PUT no longer answers an empty 204. It declares CQRSQuery: GetSqlRequestSettings::class, so the command result is replayed through the GET query and the endpoint returns the updated settings with a 200.
• Singleton resource: no identifier, read: false on the update since there is nothing to provide before the command runs.
• The SqlRequestSettingsConstraintException → 422 mapping is kept: unlike some other settings commands, SaveSqlRequestSettingsCommand really does validate its input, and the test covers it.

Tests

SqlRequestSettingsEndpointTest replaces SqlRequestSettingsEndpointTest + SqlRequestSettingsReadEndpointTest. It covers GET, PUT, the GET of the updated settings and the rejection of an unsupported encoding, chained with @depends:

• every fixture comes from the API itself — the previous write test asserted through \Configuration::get(), which is gone;
• assertions compare the complete structure, so a missing or extra field fails the test;
• the encoding is stored as an int in the configuration (utf-8 → 1) and mapped back to its string value on read, so asserting the PUT response against the GET is what actually pins that round-trip;
• the rejected update is followed by a GET asserting nothing changed.

How to test

GET  /sql-request-settings  (scope sql_management_read)  -> 200 {fileEncoding, fileSeparator}
PUT  /sql-request-settings  (scope sql_management_write) -> 200, the same payload, updated
GET  /sql-request-settings                               -> 200, identical to the PUT response
PUT  /sql-request-settings  with fileEncoding=utf-32     -> 422

Covered by SqlRequestSettingsEndpointTest.

Supersedes

• Add SQL request settings endpoint #280
• Add SQL request settings read endpoint #335

Both will be closed once the CI is green here.