docs(messaging): dissolve Modularize Delivery Kernel into owning milestones

Milestone removed; its parts now live where the refactoring reason is:
pluggable discovery and pluggable RLN membership in Logos Core
Integration Phase 3, Rate Limit Manager in Messaging API GA, RLN
enforcement in RLN on Logos Blockchain.

Fill the gaps: describe Pluggable RLN membership (scoped against the
membership interface from pm#416 to avoid duplication), drop the
vestigial waku-era 'Make Discovery Pluggable' deliverable from the QUIC
milestone, and add FURPS references and done-when criteria to the
Messaging API GA deliverables.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: igor-sirotin

content/messaging/roadmap/index.md

@@ -46,7 +46,6 @@ We use three release stages for developer-facing APIs and libraries:
 
 ### Testnet [v0.3](v03)
 
-- [ ] [Modularize Delivery Kernel](2026-modularize-delivery-kernel)
 - [ ] [Messaging API — General Availability](2026-messaging-api-general-availability)
 - [ ] [Reliable Channel API — Beta](2026-reliable-channel-api-beta.md)
 - [ ] [Chat — Beta](2026-chat-beta)

content/messaging/roadmap/milestones/2025-support-discovery-research-and-libp2p-quic.md

@@ -30,14 +30,3 @@ Replace legacy multiplexers (Yamux, Mplex) with QUIC transport. The old multiple
 
 **FURPS**:
 - S4. QUIC transport is supported for peer-to-peer message routing connections.
-
-### Make Discovery Pluggable
-
-**Owner**: Nim Messaging Team
-
-**Feature**: [nwaku](/messaging/furps/application/nwaku.md)
-
-**FURPS**:
-
-- F?. Peer exchanges feeds from the running discovery protocol (discv5 or otherwise).
-- U?. Discv5 implementation uses a defined interface, enabling it to be swapped with another discovery protocol.

content/messaging/roadmap/milestones/2026-logos-core-integration-phase-3.md

@@ -13,12 +13,28 @@ The v0.3 stage of Logos Core integration. Building on [Phase 2](2026-logos-core-
 
 ## Deliverables
 
+### Pluggable RLN membership
+
+**Owner**: Delivery Team
+
+The pluggable RLN membership interface itself is designed in [RLN on Logos Blockchain](2026-add-support-for-rln-on-lee) ([#416](https://github.com/logos-messaging/pm/issues/416)), with in-process backends (EVM, Logos Blockchain, centralized server). This deliverable makes the rest of `logos-delivery` consume RLN membership strictly through that interface — no direct blockchain or group-manager access from the kernel — so that a backend can also be provided across the Logos Core module boundary.
+
+**Done when**: An RLN membership backend can be swapped — including one provided by a Logos Core module — without changes to `logos-delivery` internals. Exercised by the POC below.
+
 ### POC: Integrate RLN module
 
 **Owner**: Delivery Team
 
 Proof of concept: the Delivery module obtains RLN credentials and validates proofs through the RLN membership Logos Core module (from AnonComms), instead of interacting with the blockchain directly. Validates the module interface ahead of the full integration in [Phase 4](2026-logos-core-integration-phase-4.md).
 
+### Make discovery pluggable in Logos Delivery
+
+**Owner**: Delivery Team
+
+Peer discovery is extracted behind a kernel discovery interface, with the embedded discv5 as the default implementation. Additional discovery sources can be plugged in and their results merged.
+
+**Done when**: The Discovery Logos Core module can be added as a peer source (see the POC below) without kernel changes, enabling the full replacement of discv5 in [Phase 4](2026-logos-core-integration-phase-4.md).
+
 ### POC: Delivery module uses Discovery module for peer discovery
 
 **Owner**: Delivery Team

content/messaging/roadmap/milestones/2026-messaging-api-general-availability.md

@@ -11,6 +11,12 @@ date: 2026-07-07
 
 The [Beta](2026-messaging-api-beta.md) delivered the full API surface (Send, Health, Subscribe/Receive in core and edge mode) plus Store access for existing applications. General Availability makes the Messaging API production-ready: anonymity via mix integration, automatic recovery of messages missed while offline, built-in rate limit management, and DST-validated reliability at scale.
 
+## FURPS
+
+- [Messaging API](/messaging/furps/core/messaging_sdk.md): R1, R2
+- [Mixnet](/messaging/furps/core/mix.md)
+- [Rate Limit Manager](/messaging/furps/application/rate_limit_manager.md)
+
 ## Risks
 
 | Risk                        | (Accept, Own, Mitigation)                                                                                                                          |
@@ -26,26 +32,47 @@ The [Beta](2026-messaging-api-beta.md) delivered the full API surface (Send, Hea
 
 Outbound messages sent through the Messaging API are routed through the mix network (libp2p mixnet, owned by AnonComms) to provide sender anonymity by default.
 
+**Feature**: [Mixnet](/messaging/furps/core/mix.md)
+
+**FURPS**:
+- F3. Client nodes can send light push requests over the mixnet before delivery to a service node.
+- F4. Client nodes can receive a response to a light push request over the mixnet.
+
 **Dependency**: mix interface from AnonComms team must be available.
 
+**Done when**: Messages sent through the Messaging API are routed over the mix network by default, with no application changes required.
+
 ### Offline periods backfill
 
 **Owner**: Delivery Team
 
 Messages missed while a node was offline are retrieved automatically on reconnect and delivered through the regular Subscribe/Receive path. Applications get a complete message stream without implementing their own Store-based recovery.
 
+**Feature**: [Messaging API](/messaging/furps/core/messaging_sdk.md)
+
+**FURPS**:
+- R2. Receives messages using peer-to-peer reliability (service node redundancy, periodic store query, periodic filter ping).
+
+**Done when**: After an offline period, a subscribed application receives all missed messages through its existing subscription, with no additional API calls.
+
 ### Integrate Rate Limit manager
 
 **Owner**: Delivery Team
 
 Integrate the Rate Limit Manager (created in [Reliable Channel API — Beta](2026-reliable-channel-api-beta.md)) into the Messaging API, so applications sending via the plain Messaging API get quota tracking and prioritized queueing without implementing it themselves.
 
+**Feature**: [Rate Limit Manager](/messaging/furps/application/rate_limit_manager.md)
+
+**Done when**: The Messaging API send path enforces the rate limit with message priorities, sharing a single per-node quota with the Reliable Channel API.
+
 ### Reliability and scale validation with DST
 
 **Owner**: Delivery Team + DST
 
 The Messaging API is QA-approved for production use. DST validates reliability and performance at scale against FURPS targets.
 
+**Done when**: A DST test report covering reliability and scale targets is available, and QA sign-off is obtained.
+
 ### Provide documentation on the API
 
 **Owner**: Delivery Team