Session: add Patch operation to /api/sessions/{id}

[addow]

Summary

• Adds PATCH /api/sessions/{id} alongside the existing PUT, restricted to ROLE_ADMIN
• Fixes a false 422 "title already used" on PUT: API Platform 3 can create a new entity object during PUT denormalization (id=null), causing UniqueEntity to flag the existing title as a conflict with itself
• PATCH correctly preserves object_to_populate and avoids this issue
• Enables partial updates without resending the full resource

Test plan

• PATCH /api/sessions/{id} with unchanged title → HTTP 200
• PATCH /api/sessions/{id} with changed title → HTTP 200
• PATCH /api/sessions/{id} with title already used by another session → HTTP 422
• PUT /api/sessions/{id} still works

[AngelFQC]

Adding PATCH is the right direction for the future AP4/Symfony7 upgrade (PATCH keeps stable merge semantics; PUT will switch to unconditional replace). A few points before merge:

1. The stated root cause doesn't hold with our current config. The false 422 you describe (PUT denormalizing into a fresh object with id=null) only happens when standard_put=true. This repo sets standard_put nowhere (0 matches in config/ and src/), and the Put op has no extraProperties, so standard_put=false. In that mode DeserializeProvider sets OBJECT_TO_POPULATE for PUT too (see DeserializeProvider.php:86: 'PUT' === $method && !($extraProperties['standard_put'] ?? false)), exactly like PATCH — so PUT keeps its id and UniqueEntity should recognize the row as itself, i.e. no false 422. How did you reproduce the 422 on PUT? Different branch/config/version?

2. No caller uses PATCH yet. The session service is makeService("sessions"), whose generic update() sends PUT (assets/vue/services/api.js:147). No Vue caller uses PATCH for sessions, so the "partial updates / fixes 422 for users" benefit doesn't materialize without a matching frontend change (not included here). Is a follow-up planned to move the session edit to PATCH?

3. Regression test. Since the reproduction is unclear, a PHPUnit API test (PATCH unchanged title → 200, PUT unchanged title → 200) would either prove the bug or confirm PUT already works.

Security (is_granted('ROLE_ADMIN')) matches the existing Put and the resource default — no concern there.