Publish partial messages

Nobody has claimed this yet.

Implements the wire-level partial-message send/receive flow (Steps 3 + 4 of #435).

## Scope

### Inbound dispatch (Step 3)
Replace the stub at `GossipRouter.kt:476` (`processPartialMessageExtension`) with the full flow:
1. Validate that local + peer both advertised `ControlExtensions.partialMessages`.
2. Get-or-create `GroupState(topic, groupId)`, mark as peer-initiated.
3. Enforce DoS caps (tracked in #449).
4. Call `handler.onIncomingRpc(from, peerStates, rpc)`.

### Outbound publish (Step 4)
Add `Gossip.publishPartial(topic, groupId, actions)` entry point:
1. Hop to pubsub event thread.
2. Get-or-create `GroupState`, reset TTL.
3. Populate `peerStates` with zero-values for mesh peers (fallback to fanout when mesh is empty).
4. Invoke `PublishActionsFn`, iterate yielded actions.
5. Per action: build `Rpc.PartialMessagesExtension{topicID, groupID, partialMessage?, partsMetadata?}`, enqueue through `GossipRpcPartsQueue` (do NOT bypass — PR #433 got this wrong).
6. Apply `nextPeerState` atomically.
7. Enforce spec MUST: omit `partialMessage` when peer supports sending partial but did not request it on this topic.

### Not in scope here
Routing-layer changes (suppress full-msg, suppress IDONTWANT, replace IHAVE) are tracked separately — see the routing-integration sub-issue of #435.

## Reference
Design: [`docs/partial-messages.md` §4.3, §5, §6.2](../blob/develop/docs/partial-messages.md) (lands with the first PR on #435).
go-libp2p: `extensions.go:221`, `partialmsgs.go:216, 303`.

Start with GossipRouter.kt:476 and read docs/partial-messages.md sections 4.3, 5, and 6.2, then compare the referenced go-libp2p extensions.go:221 and partialmsgs.go:216, 303. Trace the Gossip.publishPartial entry point and GossipRpcPartsQueue; done means inbound dispatch and outbound queuing follow the listed scope, including peer-state updates and the partialMessage omission requirement.

Written by the indexing model from the issue text.