fix: preload all protocol classes to avoid ClassNotFoundException in encode path

[LXingYun]

Summary

Fixes lazy loading bug in ProtocolClassLoader that causes
ClassNotFoundException when encoding commands (e.g. TopicMessageCodec.doEncode
calling TopicPayload.of(...)).

Fixes: jetlinks/jetlinks-supports#38

Approach

Add a static {} initializer block to JetLinksProtocolSupportProvider
that walks all .class entries within the running JAR and calls
Class.forName(name, false, classLoader) on each org/jetlinks/protocol/official/*
entry. This preloads all classes into the ProtocolClassLoader cache,
so subsequent runtime references hit the cache instead of triggering
the broken findClass path.

Trade-offs

Pros	Cons
Minimal diff (single file + static block)	Adds ~50ms startup cost (one-time, ~100 classes)
Cherry-pickable to all 3.x branches	Doesn't fix root cause in ProtocolClassLoader
Battle-tested in SBOMP production-like env (1000-device load test)	Best-effort: class load failures are silently swallowed

Test results

• Before: TopicMessageCodec.encode fails with NoClassDefFoundError 100% on first command dispatch
• After: 1000 commands dispatched without error in SBOMP P0 1h soak test
• Decode path unaffected (continues to work as before)

Alternative considered

Fix at ProtocolClassLoader (jetlinks-supports). Likely a better long-term
fix but requires changes to multiple package boundaries. Submitting this
patch as a quick win; willing to follow up with a deeper fix in
jetlinks-supports if maintainers prefer.

Co-author

This patch was developed at SBOMP,
a smart building operations platform built on JetLinks.