ci: add integration test for session replication

[heruan]

Summary

• Adds a GitHub Actions workflow that builds the demo app as a Docker image (Spring Boot Buildpacks, Redis backend), deploys it to a kind cluster with Envoy Gateway and sticky session cookies, and runs a Playwright Java/JUnit test that verifies session replication works across pod failures
• The test navigates to the PushCounterView, increments the counter, deletes the serving pod, waits for Vaadin's push reconnection, and asserts the counter state was preserved on the surviving pod
• Adds an integration-test Maven profile to the demo module with Playwright and maven-failsafe-plugin dependencies

Test plan

• Integration test workflow runs successfully on this branch (triggered via push)
• Playwright test passes: counter value preserved after pod deletion, hostname changes
• Revert the temporary branch trigger commit before merging

[github-actions]

Test Results

 35 files  ±0   35 suites  ±0   29s ⏱️ ±0s
179 tests ±0  178 ✅ ±0   1 💤 ±0  0 ❌ ±0 
236 runs  ±0  203 ✅ ±0  33 💤 ±0  0 ❌ ±0 

Results for commit a76fa00. ± Comparison against base commit 66bd0e3.

♻️ This comment has been updated with latest results.

[mcollovati]

I think it would be good to add integration tests that run with the serialization debug tool without the need for a Kubernetes cluster. Those tests could be executed locally to get early feedback about serialization issues; they could possibly run for every PR

Given that, I would rename the workflow file to something more specific, like kubernetes-test.yml for example.
In addition, I'd suggest adding a @Tag("kubernetes") to the integration test class and configuring failsafe to not run them by default. The workflow should then provide a system parameter to activate that tag only

Another point to consider is to run the same test also with Hazelcast. I'm not sure what could be the best way; it might be separated jobs or just conditional steps based on an input with default redis, so Hazelcast can only be dispatched manually.
But can be improved later or.

The last one (also doable separately) is to clean up the demo POM. It still runs prepare-frontend and has the separated production profile.

[heruan]

Depends on #283 to fix flaky tests.