fix(localdb): preserve the poison cause when dead-lettering itself fails; pin self-referencing cascade (0.3.3 review follow-ups)

Three review follow-ups on 122940c. Still 0.3.3 — unpublished, so no further
version bump. No behaviour change to any succeeding path.

- The per-entry poison handler's recovery work (ROLLBACK TO + the dead-letter
  INSERT) was unguarded: a wedged connection, an I/O error, or a dead-letter
  INSERT that faults would propagate the SECOND exception and silently discard
  the FIRST — the one that says why the entry was poison at all. The pair is now
  wrapped; a recovery failure throws an AggregateException whose message names
  the entry (table + seq) and the recovery fault, and whose InnerException is the
  ORIGINAL entry fault, with the recovery fault carried alongside it at
  InnerExceptions[1] with its own stack. The outcome is unchanged and still
  fail-closed: nothing commits, and disposing the batch transaction unwinds it.
  OperationCanceledException is deliberately excluded from the wrap so a
  shutdown still surfaces as a cancellation rather than as a fault. No upstream
  caller catches SqliteException from the apply path (checked), so widening the
  escaping type is safe.

  Injected cheaply after all: a RAISE(ABORT) trigger on __localdb_dead_letter,
  stacked on the existing row-version poison trigger, produces exactly the
  two-fault case with no production test seam. The test asserts both causes are
  carried AND that the batch committed nothing — the entry that applied cleanly
  before the poison one is gone and the peer watermark never moved.

- Register_SelfReferencingCascade_Throws pins the README's "or from itself"
  claim: a table that is its own cascading parent (parent_id REFERENCES
  nodes(id) ON DELETE CASCADE) is refused. The guard needed no special case —
  it reads every foreign key in the database — but the promise is now tested.

- Comment on why EnterEntryAsync sits outside the try: a SAVEPOINT that failed
  opened nothing, so a handler ROLLBACK TO would name a savepoint that does not
  exist and fault in turn.

Both new tests were run against 122940c first and fail there: the self-reference
case throws nothing, and the stacked-fault case escapes as a bare
SqliteException("dead-letter write failed") with the original cause gone.

Suite: 215/215 green, build 0 warnings / 0 errors.

ZB.MOM.WW.LocalDb/src/ZB.MOM.WW.LocalDb.Replication/Internal/LwwApplier.cs

@@ -98,6 +98,9 @@ internal sealed class LwwApplier(SqliteLocalDb db, Func<DateTimeOffset>? utcNow
             // the row died), or an upsert whose new row carries the OLD version and therefore loses
             // the next LWW comparison it should win. A per-entry savepoint makes the pair
             // all-or-nothing without widening the poison catch to the whole batch.
+            //
+            // Opened OUTSIDE the try on purpose: a SAVEPOINT that failed opened nothing, so the
+            // handler's ROLLBACK TO would name a savepoint that does not exist and fault in turn.
             await sql.EnterEntryAsync(ct);
             try
             {
@@ -117,8 +120,27 @@ internal sealed class LwwApplier(SqliteLocalDb db, Func<DateTimeOffset>? utcNow
                 // statement, not the transaction, so the batch continues after dead-lettering.
                 // Any other exception propagates with the savepoint still open, and disposing the
                 // outer transaction unwinds the whole batch (fail-closed).
-                await sql.RollbackEntryAsync(ct);
-                await sql.DeadLetterAsync(entry, ex.Message, utcNow, ct);
+                try
+                {
+                    await sql.RollbackEntryAsync(ct);
+                    await sql.DeadLetterAsync(entry, ex.Message, utcNow, ct);
+                }
+                catch (Exception recoveryFailure) when (recoveryFailure is not OperationCanceledException)
+                {
+                    // Recovering from the poison entry itself failed — a wedged connection, an I/O
+                    // error, a dead-letter INSERT that faults. The outcome is unchanged and still
+                    // fail-closed (nothing commits; disposing the batch transaction unwinds it),
+                    // but reporting only the recovery failure would throw away the ORIGINAL cause,
+                    // which is the one that says WHY this entry is poison. Both are carried out:
+                    // the original as InnerException (AggregateException surfaces the first inner
+                    // there), the recovery failure alongside it with its own stack intact.
+                    throw new AggregateException(
+                        $"Failed to dead-letter a poison oplog entry for table '{entry.TableName}' " +
+                        $"(seq {entry.Seq}): {recoveryFailure.Message}. The entry's own fault is the " +
+                        "inner exception. The batch is not committed.",
+                        ex, recoveryFailure);
+                }
+
                 deadLettered++;
             }
         }