feat(storage): standardize storage SPI capabilities + TCK (issue #5303)

[qqeasonchen]

What

Single PR that closes #5303 — standardizes storage SPI capabilities via a typed marker pattern, and ships a JUnit 5 TCK every backend must pass.

Why

The existing MeshStoragePlugin interface is rich but backend-specific behaviors (end-offset query, pull-cursor rewind, deferred POP ACK, lite topic) are scattered between MeshStoragePlugin default methods, the standalone LiteTopicCapable interface, and ad-hoc instanceof checks on concrete classes (e.g. createTopic). Callers have to know per-backend which features are supported, and there's no shared test base that catches an accidental removal of a capability override.

What changes

New (in eventmesh-storage-api)

• StorageCapabilities — outer interface grouping 7 capability sub-interfaces
• tck.MeshStoragePluginTCK — abstract JUnit 5 test base
• InMemoryStoragePlugin (test scope) — fixture implementing all 7 capabilities
• tck.MeshStoragePluginTCKSelfTest (test scope) — runs the TCK against the in-memory fixture

Modified

• KafkaMeshStoragePlugin declares 5 capabilities (universal 3 + EndOffsetQuery + AlignPullOffset)
• RocketMQRemotingStoragePlugin declares 4 (universal 3 + AlignPullOffset)
• RocketMQ5RemotingStoragePlugin declares 5 (universal 3 + DeferredPopAck + LiteTopic)
• 3 new *MeshStoragePluginTCKTest classes wire the TCK for each backend
• 3 build.gradle files add junit-jupiter + useJUnitPlatform

Capability matrix

Capability	Kafka	RocketMQ 4.x	RocketMQ 5.x
TopicManagement	✅	✅	✅
PartitionAssignment	✅	✅	✅
ExplicitOffsetCommit	✅	✅	✅
EndOffsetQuery	✅	❌	❌
AlignPullOffset	✅	✅	❌
DeferredPopAck	❌	❌	✅
LiteTopic	❌	❌	✅

The 3 universal capabilities are part of the MeshStoragePlugin contract already; declaring them via StorageCapabilities is a self-audit so dropping a method body by accident fails the TCK, not a smoke test. The 4 backend-specific capabilities are new — they correspond to existing behavior that was previously undiscoverable.

Test results

40 tests across 4 modules, 0 failures:

eventmesh-storage-api:        10/10  (TCK self-test against InMemoryStoragePlugin)
eventmesh-storage-kafka:      10/10  (TCK wiring for KafkaMeshStoragePlugin)
eventmesh-storage-rocketmq:   10/10  (TCK wiring for RocketMQRemotingStoragePlugin)
eventmesh-storage-rocketmq5:  10/10  (TCK wiring for RocketMQ5RemotingStoragePlugin)

Out of scope (separate issues)

• ArchUnit rule asserting every plugin in eventmesh-storage-* implements the 3 universal capabilities — needs the eventmesh-architecture-guard module that [Architecture Review][P2] Gradle dependency guardrails (architectureCheck) #5305 added to develop. This PR stays on master (ba267195c); when this PR merges, a follow-up can carry the ArchUnit rule over.
• LiteTopicCapable deprecation — the historical interface is still around and still used by callers; consolidating it with StorageCapabilities.LiteTopic can be a follow-up.

How a backend wires in

class KafkaMeshStoragePluginTCKTest extends MeshStoragePluginTCK<KafkaMeshStoragePlugin> {
    @Override protected KafkaMeshStoragePlugin newPlugin() { return new KafkaMeshStoragePlugin(); }
    @Override protected Set<Class<?>> expectedCapabilities() {
        return Set.of(TopicManagement.class, PartitionAssignment.class,
                      ExplicitOffsetCommit.class, EndOffsetQuery.class,
                      AlignPullOffset.class);
    }
}

Closes #5303.

[qqeasonchen]

Force-pushed to fix checkstyle ImportOrder violations in MeshStoragePluginTCK.java (2 warnings on ). No code changes — only import group ordering. Verified locally: all 4 storage modules pass ./gradlew :check (compile + test + checkstyle + spotbugs). Awaiting CI re-run.