Fix KryoSerializer ThreadLocal ClassLoader leak in web containers

[Copilot]

KryoSerializer holds a ThreadLocal<Kryo> on an enum singleton (effectively static) with no cleanup path. In containers like Tomcat that reuse threads across redeployments, this pins the WebappClassLoader via: Thread → ThreadLocalMap → Kryo → Kryo.class → WebappClassLoader, causing repeated OutOfMemoryError: Metaspace.

Changes

• Serializer — adds a default void reset() no-op, giving callers a type-safe cleanup contract without breaking existing implementations.
• KryoSerializer — overrides reset() to call kryos.remove(), severing the reference chain.
• SerializerTestCase — adds testKryoResetClearsThreadLocal verifying reset() completes without error and the serializer remains fully functional afterward (lazy re-initialization).

Usage

Register a ServletContextListener and call reset() per worker thread on shutdown:

public void contextDestroyed(ServletContextEvent sce) {
    // call from each container thread, e.g. via an ExecutorService
    KryoSerializer.INSTANCE.reset();
}

Or use it generically through the Serializer interface if the concrete type is unknown:

Serializer serializer = redisConfig.getSerializer();
serializer.reset(); // no-op for JDKSerializer, removes ThreadLocal for KryoSerializer

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[coveralls]

coverage: 82.915% (-0.2%) from 83.163%
when pulling 9624bef on copilot/review-issue-351
into 47da9d7 on master.