release(v4.8.4): server-side cross-channel dedup via BridgeDeliveryLog

V4.8.3 shipped client-side cross-channel dedup hook
(`Inbox.acceptBridgeFrame`), but recipients that didn't migrate to
the new wiring still observed the same envelope twice — once via
WS bridge push, again ~30 s later via inbox-poll. Prism re-verified
the FR after 4.8.3 and asked for a relay-side enforcement so app
code doesn't have to ack-via-DELETE on every bridge frame.

V4.8.4 adds an in-memory `BridgeDeliveryLog` (default 60 s grace,
8192-per-address cap) that records every successful WS / SSE /
long-poll push of `(address, msgId)`. The `/v1/inbox/:addr/fetch`
route filters out blobs in the log's grace window so a recipient
running both a bridge and the 30 s poll cadence sees exactly one
delivery. Cursor advances over the full fetched window so a poll
that straddles a suppressed blob doesn't stall.

The standalone server auto-wires the log between
`createBridgeRoutes` and `createInboxRoutes`. Custom mounts thread
the same instance through `bridgeDeliveryLog` on both factories.

Tests cover WS-then-poll, SSE-then-poll, and a negative control
(non-bridge-pushed blob still comes through inbox-fetch).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

CHANGELOG.md

@@ -5,6 +5,93 @@ All notable changes to Shade are documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [4.8.4] — 2026-05-08 — Server-side cross-channel dedup via `BridgeDeliveryLog`
+
+V4.8.3 shipped the *client-side* cross-channel dedup hook
+(`Inbox.acceptBridgeFrame`), but a recipient that didn't migrate to
+the new wiring kept observing the same envelope twice — once via the
+WS bridge push, again ~30 s later when the next inbox-poll cycle
+fetched it. Prism re-verified the FR after 4.8.3 and called this out:
+they wanted the relay itself to enforce the
+"one `Inbox.send` ⇒ one observable delivery" contract so app code
+doesn't have to ack-via-DELETE on every bridge frame.
+
+V4.8.4 adds the **server-side** dedup gate. A new in-memory
+`BridgeDeliveryLog` (default 60 s grace, 8192-entry-per-address cap)
+records every successful WS / SSE / long-poll push of
+`(address, msgId)`. The inbox-fetch route reads the log and filters
+out blobs the bridge has already pushed within the grace window. The
+cursor advances over the *full* fetched window so a poll cycle that
+straddles a suppressed blob doesn't get stuck — the bridge frame is
+the canonical delivery; a recipient that crashed before processing it
+falls back to ack-via-DELETE or waits for TTL the same way it would
+in a no-bridge deployment.
+
+The standalone server (`@shade/server`) auto-wires the log between
+`createBridgeRoutes` and `createInboxRoutes`, so self-hosted relays
+get the fix without configuration. Custom mounts thread the same
+instance through `bridgeDeliveryLog` on both factories.
+
+Reported by Prism (multi-device E2EE terminal). Acceptance: a single
+`inbox.send` from sender A produces exactly one observable receive
+on recipient B even when B runs both a bridge subscription and the
+30 s `Inbox.pollOnce` cadence — confirmed by `bun test
+packages/shade-transport-bridge/tests/bridge.test.ts`'s new
+"BridgeDeliveryLog" describe block (WS + SSE coverage).
+
+### Added
+
+#### `@shade/inbox-server`
+- `BridgeDeliveryLog` class — in-memory `Map<address, Map<msgId,
+  deliveredAt>>` with grace-window filtering. Bounded per address
+  (default 8192, oldest-first eviction); lazy cleanup on insert.
+  Exported from the package root.
+- `BridgeDeliveryLogOptions` — `{ graceMs?, maxPerAddress? }`.
+- `createBridgeRoutes(...).bridgeDeliveryLog` — the auto-created log
+  the bridge handlers write to. Inject one explicitly via
+  `BridgeRoutesOptions.bridgeDeliveryLog` when you need to share an
+  instance across multiple bridge mounts.
+- `InboxRoutesOptions.bridgeDeliveryLog` — when provided, the
+  `/v1/inbox/:addr/fetch` route filters out blobs in the log's
+  grace window. Cursor advances over the *full* unsuppressed-plus-
+  suppressed page so successive polls don't stall.
+- `createInboxServer({ bridgeDeliveryLog })` — opt-in for the
+  high-level factory.
+
+#### `@shade/server` — `standalone.ts`
+- The shared `BridgeDeliveryLog` is auto-wired between
+  `createBridgeRoutes` and `createInboxRoutes` so self-hosted
+  relays inherit the cross-channel dedup with zero configuration.
+
+### Tests
+- `packages/shade-transport-bridge/tests/bridge.test.ts` — new
+  "BridgeDeliveryLog" describe block:
+  1. WS push then `/v1/inbox/:addr/fetch` returns 0 blobs but the
+     cursor has advanced.
+  2. SSE push records into the log identically (transport parity).
+  3. A blob the bridge never pushed (e.g. bridge wasn't connected)
+     still comes through inbox-fetch — the filter is bridge-
+     delivered-specific, not a blanket suppression.
+- `bootstrap()` in the test file now wires the bridge's
+  auto-created log into `createInboxRoutes`, mirroring the
+  standalone-server wiring.
+
+### Migration
+
+For self-hosted operators of the standalone server: drop-in.
+
+For consumers that mount `createInboxRoutes` + `createBridgeRoutes`
+themselves: pass the same `bridgeDeliveryLog` to both factories. The
+bridge auto-creates one and exposes it as
+`bridgeRoutes.bridgeDeliveryLog`; the inbox routes accept it as
+`InboxRoutesOptions.bridgeDeliveryLog`. Without the wiring, the bridge
+push still works as before but the cross-channel dedup is off.
+
+For client-side consumers, V4.8.3's `Inbox.acceptBridgeFrame` is
+still the recommended path (instant ack, no grace-window wait), but
+clients that only consume bridge pushes via their own dispatcher now
+get the dedup for free as long as the relay is on V4.8.4.
+
 ## [4.8.3] — 2026-05-08 — Cross-channel msgId dedup + `Shade.aliasSession`
 
 Two follow-ups to the V4.8.2 duplicate-fan-out fixes Prism filed