Cherry-pick Messaging-API migration (community-control shard 32 + version=0 receive) to develop

[igor-sirotin]

What

Forward-port (cherry-pick) the two Messaging-API migration changes that were merged into release/10.34.x onto the develop branch, so the work isn't lost when the release branch is eventually retired and so develop-based releases interoperate.

Both PRs were intentionally merged to the release branch first (for v2.38 / 10.34.x), but the same receive-side logic must also live on develop.

PRs to cherry-pick

• feat: listen for community control messages on the default shard (32) #7495 — feat: listen for community control messages on the default shard (32) (merge 34aa2978f4a6a2fb6c609dfc57f121879561638a)
  • Phase 1 of Migrate all traffic to a single shard (32) #7498 (single-shard migration). Purely additive: DefaultFilters also registers the community broadcast topic on the default shard (32) so clients listen on 32 before publishing moves there.
• feat(messaging): decode incoming version=0 payloads as WakuV1 #7500 — feat(messaging): decode incoming version=0 payloads as WakuV1 (merge 2f5739c1f664da8f0c504fd90cdbc3556b37cde3)
  • Phase 1 of Migrate off the WakuMessage version field #7499 (retire WakuMessage version field). Receive side only: decode incoming version=0 envelopes as WakuV1-encrypted when the matching filter has a decryption key.

Why

These are the N±1 interop prerequisites for adopting the Logos Delivery Messaging API (logos-messaging/pm#380). Receivers must learn to accept the new behaviour (listen on shard 32; accept version=0-as-encrypted) on every branch — including develop — before any sender emits it. If they land only on release/10.34.x, develop releases would break interop once publishing switches.

Notes

• feat(messaging): decode incoming version=0 payloads as WakuV1 #7500 on the release branch still uses go-waku's payload codec and deliberately does not depend on refactor(messaging): relocate rfc26 encoding to status-go #7484 (codec relocation, develop-only). When forward-porting, reconcile with refactor(messaging): relocate rfc26 encoding to status-go #7484 already present on develop.
• Both changes are receive-side only; no sending behaviour changes.

Parent: logos-messaging/pm#380

[igor-sirotin]

Note that direct cherry-pick might not work, because I'm heavily changing this part of code in #7484