watchlist add: event only if inserted; adr 0015 jetstream/relay accuracy; drop vacuous assert

docs/adr/0015-transactional-outbox.md

@@ -25,8 +25,17 @@ Use cases never open transactions; the adapter does.
 **The server never talks to NATS.** With `EVENT_BUS_BACKEND=nats` the server still only inserts
 outbox rows. The worker runs a relay that claims pending rows and publishes them to JetStream with
 `Nats-Msg-Id` set to the event id, then marks the row done. With `db` the worker consumes the rows
-directly. `max_deliver` on the JetStream consumer equals `EVENT_QUEUE_MAX_ATTEMPTS`, so both
-backends dead-letter after the same number of attempts.
+directly. `max_deliver` on the JetStream consumer equals `EVENT_QUEUE_MAX_ATTEMPTS`, and a JetStream
+nak uses the same backoff as the SQLite queue (`domain::events::retry_backoff`: 5 s doubling per
+attempt, capped at 300 s), so both backends give up after the same number of deliveries on the same
+schedule. They differ in what giving up means. SQLite marks the row `dead_lettered`. JetStream has no
+DLQ: after `max_deliver` the message is no longer delivered but stays in the stream (until stream
+limits evict it). The consumer logs `event exhausted max deliveries` at error level with the event id
+on the final nak. To find such messages, watch the JetStream max-deliveries advisory
+(`$JS.EVENT.ADVISORY.CONSUMER.MAX_DELIVERIES.<stream>.<consumer>`) or inspect the stream
+(`nats stream view <stream>`) for sequences the consumer has not acked. The relay never spends
+attempts on transport failures: when the bus is unreachable it defers the row with growing backoff and
+pauses, so an outage cannot dead-letter rows.
 
 **Three dedup layers.**
 1. *Broker.* JetStream drops a repeated `Nats-Msg-Id` inside `duplicate_window`, set explicitly to 1