Describe the bug When using Operaton BPM with a Spring Boot backend that also uses Keycloak authentication, the JSESSIONID cookie is overwritten by frontend requests.
This happens because Operaton hardcodes the cookie name, and currently the only way to change it is via the Spring Boot property server.servlet.session.cookie.name.
This causes conflicts when both the backend and Operaton share the same Spring Boot application. The issue occurs in a localhost environment.

To Reproduce Steps to reproduce the behavior:

1. Run a Spring Boot backend application.
2. Include the module org.operaton.bpm.springboot:operaton-bpm-spring-boot-starter-webapp with Keycloak plugin enabled.
3. Access the Operaton cockpit with Keycloak users (works as expected).
4. Use a frontend that calls backend services with Keycloak authentication.
5. Notice that every frontend update overwrites the JSESSIONID cookie, causing session conflicts.

Expected behavior Operaton should allow configuring its session cookie name independently from the backend, so that both can coexist without conflicts.

Proposed solution Introduce a new property in application.properties/application.yaml under operaton.bpm.* to configure the session cookie name specifically for Operaton, e.g., operaton.bpm.session.cookie.name.

• Default behavior should still use JSESSIONID to avoid breaking changes.
• The old method via server.servlet.session.cookie.name should continue to work for backward compatibility.
• In a future major version, the old method can be deprecated in favor of the new property.

Additional context

• Operaton version: 1.0.0