Summary

Add the library-owned `JwtCookieAuthenticationFilter` that reads the auth cookie from incoming requests, delegates JWT validation to the host's `JwtCookieTokenService` SPI, builds a fully-resolved `CamundaAuthentication` via `LazyTokenClaimsConverter` (backed by `MembershipPort`), and populates the Spring Security context. This is the runtime piece that replaces Optimize's three `CCSMAuthenticationCookieFilter` variants.

Parent Feature

#162

Why This Is Independently Mergeable

The filter class is added to the library but not registered in any chain yet. Without a host importing the upcoming `OidcJwtCookieWebappSecurityConfiguration` (next task) and providing a `JwtCookieTokenService` and `MembershipPort` bean, the class is unreachable at runtime. Pure additive change behind missing dependencies.

Scope

In scope:

• New `JwtCookieAuthenticationFilter` extending `OncePerRequestFilter`.
• Reads cookie by configured name, calls `JwtCookieTokenService.validate(cookieToken)` to get the decoded claims map.
• Passes the claims map to `LazyTokenClaimsConverter.convert(claims)` to build a `CamundaAuthentication` with lazily-resolved `MembershipPort` chains — identical to the pattern used by `OidcTokenAuthenticationConverter` in the bearer chain.
• Sets the resulting `CamundaAuthentication`-backed `Authentication` in `SecurityContextHolder` on success.
• Delegates to `OidcAuthenticationEntryPoint` on failure (missing cookie, invalid token, validation exception).
• Unit tests covering: valid cookie path (CamundaAuthentication placed in context), missing cookie, invalid token (validation exception), already-authenticated request (filter skipped).

Out of scope:

• Chain wiring (next task).
• Cookie issuance — that lives in the host's `JwtCookieTokenService` implementation invoked from the login success handler.
• Logout cookie clearing — separate concern, addressed in the `Lift CamundaOidcLogoutSuccessHandler into CSL to preserve OIDC RP-initiated logout #70` family if/when it lands here.
• `MembershipPort` implementations — host responsibility; Optimize ships three in the adoption task.

Location in Code

• New: `spring-boot-starter/src/main/java/io/camunda/security/spring/filter/JwtCookieAuthenticationFilter.java`
• New tests: `spring-boot-starter/src/test/java/io/camunda/security/spring/filter/JwtCookieAuthenticationFilterTest.java`

Pattern to follow:

• `WebAppAuthorizationCheckFilter` (delivered under feat(csl-adapters): lift WebAppAuthorizationCheckFilter #129) for filter shape + SPI delegation idiom.
• `OidcTokenAuthenticationConverter` for the claims → `CamundaAuthentication` conversion step: extract claims from IdP-specific token, pass to `LazyTokenClaimsConverter`.
• Optimize's existing `CCSMAuthenticationCookieFilter` for the cookie-read / token-validate flow (the implementation being generalised here).

Acceptance Criteria

• `JwtCookieAuthenticationFilter` exists, is `final`, and extends `OncePerRequestFilter`.
• Filter reads a cookie whose name is supplied by configuration (defaults documented in javadoc).
• On successful validation, `JwtCookieTokenService.validate()` is called, the returned claims map is passed to `LazyTokenClaimsConverter.convert()`, and the resulting `CamundaAuthentication`-backed `Authentication` is set in `SecurityContextHolder`.
• `CamundaAuthentication` produced by the filter has lazy `MembershipPort` backing for group, role, tenant, and mapping-rule fields — verified by a unit test that stubs `MembershipPort` and asserts it is called only when the corresponding field is first read.
• On validation failure or missing cookie when authentication is required, the filter delegates to the injected `OidcAuthenticationEntryPoint`.
• Unit tests cover: valid token, expired/invalid token, missing cookie, already-authenticated request (no-op), host-thrown validation exception translates to an unauthenticated response.
• No chain configuration is touched in this task.

Verification

```
mvn verify -pl spring-boot-starter -Dtest=JwtCookieAuthenticationFilterTest
mvn verify -pl spring-boot-starter
```

Additional Context

• Part of M3: Authentication in Optimize is provided by CSL #162.
• Depends on the SPIs from the preceding task (feat(spring-boot-starter): add JwtCookieTokenService and OidcAuthenticationEntryPoint SPIs for stateless-cookie chain #163) and `LazyTokenClaimsConverter` (already exists in `spring-boot-starter`).
• Filter placement / order will be decided in the chain-config task; this task just provides the class.
• The conversion chain mirrors the bearer chain exactly: `validate()` plays the role of Spring's JWT decoder/validator; `LazyTokenClaimsConverter` plays the role it already plays in `OidcTokenAuthenticationConverter`; `MembershipPort` resolves memberships lazily on first field access.