Merge the CustomerService / CustomerThread endpoints into one domain PR

[PrestaEdit]

Questions	Answers
Branch?	dev
Description?	Consolidates the five pending CustomerService / CustomerThread PRs into one domain PR, fixes a wrong URI prefix and moves every assertion onto the API
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 #244, #291, #323, #281 and #381 into one PR, following the mutualisation done on the Product domain in #410.

Endpoints

Method	URI	CQRS	Scope
GET	/customer-threads/{customerThreadId}/details	GetCustomerThreadForViewing	customer_service_read
PUT	/customer-threads/{customerThreadId}/set-status	UpdateCustomerThreadStatusCommand	customer_service_write
PUT	/customer-threads/{customerThreadId}/messages	ReplyToCustomerThreadCommand	customer_service_write
POST	/customer-threads/{customerThreadId}/forwards	ForwardCustomerThreadCommand	customer_service_write
DELETE	/customer-threads/{customerThreadId}	DeleteCustomerThreadCommand	customer_service_write
DELETE	/customer-threads/bulk-delete	BulkDeleteCustomerThreadCommand	customer_service_write
GET	/customer-services/signatures/{languageId}	GetCustomerServiceSignature	customer_service_read

Why #381 is in here

The original grouping put #281 and #381 together because both classes sat in Resources/CustomerService/. That namespace was the problem, not the grouping.

ApiResourceUriTemplateRector derives the first URI segment from the resource namespace. Because CustomerThreadForward was declared under CustomerService, the rule forced /customer-services/{customerThreadId}/forwards — a customer thread id addressed under the customer-services prefix, while the other four thread endpoints used /customer-threads/{customerThreadId}/.... The source branch even carries a commit named "Fix Rector ApiResourceUriTemplateRector (customer-services prefix)", which bent the URI to satisfy the rule instead of moving the class.

Here the class moves to the CustomerThread namespace and the URI becomes /customer-threads/{customerThreadId}/forwards. Same fix for its scope: it declared customer_thread_write, which exists nowhere else — every other resource in the domain uses customer_service_write.

CustomerServiceSignature genuinely belongs to CustomerService (/customer-services/signatures/{languageId}) and stays where it is.

Tests

The three customer-thread test classes become one CustomerThreadEndpointTest.

On fixtures: customer threads are created by the front-office contact form. The CustomerService domain exposes no "add thread" command, so there is no Admin API way to create one — a thread still has to be seeded through the legacy CustomerThread object. What changed is that this now happens in one documented helper instead of three slightly different copies, and every assertion goes back through the API:

Was	Now
new \CustomerThread($id)->status after set-status	the actions of the details endpoint — an open thread offers closed, a closed one offers open
SELECT COUNT(*) FROM ps_customer_message after reply	the messages of the details endpoint, content included
Validate::isLoadedObject() after delete / bulk-delete	the details endpoint answering 404

The forward endpoint also gets an actual test — #381 shipped with none, only the getProtectedEndpoints() declaration. Forwarding builds its email from the thread's last message, so the test chains it after the reply, which is only possible now that both endpoints live in the same PR.

⚠️ Core dependency

POST /customer-threads/{customerThreadId}/forwards requires PrestaShop/PrestaShop#42047. ForwardCustomerThreadCommand::__construct() is private on the current cores — the command is only reachable through its toAnotherEmployee() / toSomeoneElse() named constructors, which the serializer cannot use. testForwardCustomerThread stays red until that core PR is merged into the target branches. Every other endpoint here is independent of it.

How to test

GET    /customer-threads/{id}/details      -> 200
PUT    /customer-threads/{id}/set-status   -> 204, then the details actions change
PUT    /customer-threads/{id}/messages     -> 204, then the details messages contain the reply
POST   /customer-threads/{id}/forwards     -> 204, then the details gain a message  (needs core #42047)
DELETE /customer-threads/{id}              -> 204, then the details answer 404
DELETE /customer-threads/bulk-delete       -> 204, then each details answers 404
GET    /customer-services/signatures/{id}  -> 200

Covered by CustomerThreadEndpointTest and CustomerServiceSignatureEndpointTest.

Supersedes

• Add CustomerService thread management endpoints #244
• Add customer service signature read endpoint #281
• Add Customer thread details read endpoint #291
• Add customer thread reply endpoint #323
• Add ForwardCustomerThread Admin API endpoint #381

All five will be closed once the CI is green here.