@@ -119,6 +119,17 @@ public sealed class CachedHostToTenantResolver(
     /// a round trip the next request would repeat. An earlier version of this sentence
     /// said the negative cache is "populated only by a request that survived its own
     /// lookup", which the publication block below contradicts in the same file.
+    ///
+    /// <b>What bounds the flights.</b> The dictionary does not: a flight is registered
+    /// per host and retired in the read's <c>finally</c>, so its size is the number of
+    /// lookups in flight, never the number of hosts ever seen. The ceiling is the Npgsql
+    /// pool — each cold lookup takes a connection, and past the pool maximum the rest
+    /// queue in <c>OpenConnectionAsync</c> rather than opening more. A distributed flood
+    /// of novel hostnames therefore degrades into queueing on that pool: the anonymous
+    /// rate limiter bounds one peer, the negative cache bounds repeats, and neither
+    /// bounds first sight. A process-wide admission gate for cold lookups is the remedy
+    /// if that shows up; it is not built, because the trigger for it is a measurement
+    /// nobody has taken.
     /// </remarks>
     private async Task<HostResolution?> ReadCoalescedAsync(
         string host, string key, CancellationToken cancellationToken)
 
@@ -125,6 +125,28 @@ internal static async Task SaveTranslatingConflictsAsync(
         catch (DbUpdateException failure)
             when (failure.InnerException is PostgresException { SqlState: "23505" } conflict)
         {
+            // Detach what the database refused, before the exception leaves. EF keeps a
+            // failed entry in the state it had — an Added row stays Added — so a caller
+            // that turns this into Result.Fail and carries on writing has the rejected
+            // INSERT still queued, and the NEXT SaveChanges on this context re-sends it.
+            //
+            // Reachable through nesting, which is the shape ADR-0040 permits: an outer
+            // handler may absorb an inner failure and keep going on the same scope, and
+            // the scope is one DbContext. The row is gone from the database either way —
+            // the statement was refused — so the tracker holding it is a claim that
+            // outlived its subject.
+            //
+            // Added only. A Modified entry's original values are what the database still
+            // holds, so leaving it tracked is correct; detaching it would discard a change
+            // the caller may legitimately retry.
+            foreach (var entry in failure.Entries)
+            {
+                if (entry.State == EntityState.Added)
+                {
+                    entry.State = EntityState.Detached;
+                }
+            }
+
             throw new AggregateConflictException(
                 conflict.MessageText, conflict.ConstraintName, failure);
         }
 
@@ -8,6 +8,7 @@
 using LearnStack.Modules.Tenancy.Domain;
 using LearnStack.Modules.Tenancy.Infrastructure.Persistence;
 using LearnStack.SharedKernel.Identifiers;
+using LearnStack.SharedKernel.Errors;
 using LearnStack.SharedKernel.Persistence;
 using LearnStack.SharedKernel.Results;
 using LearnStack.SharedKernel.Tenancy;
@@ -417,6 +418,61 @@ public async Task Updating_a_detached_aggregate_is_refused_rather_than_guessed_a
         await unitOfWork.RollbackAsync();
     }
 
+    [Fact]
+    public async Task A_refused_write_does_not_ride_along_on_the_next_save()
+    {
+        // EF keeps a failed entry in the state it had, so an Added row the database
+        // refused stays Added. A caller that turns the conflict into Result.Fail and
+        // carries on writing therefore has the rejected INSERT still queued, and the next
+        // SaveChanges on the same context re-sends it — the row is gone from the database,
+        // and the tracker is a claim that outlived its subject.
+        //
+        // Reachable through nesting, which ADR-0040 permits: an outer handler may absorb
+        // an inner failure and keep going on the same scope, and the scope is one
+        // DbContext. Driven directly here, because what is under test is the store's
+        // cleanup and not the pipeline that would carry it.
+        await using var provider = BuildProvider();
+        await using var scope = provider.CreateAsyncScope();
+        var services = scope.ServiceProvider;
+
+        services.GetRequiredService<ITenantContextAccessor>().Current =
+            new ResolvedContext(SchemaFixture.TenantA, SchemaFixture.OrgA1);
+
+        var unitOfWork = services.GetRequiredService<IUnitOfWork>();
+        await unitOfWork.BeginTransactionAsync();
+        await unitOfWork.SetTenantContextAsync(services.GetRequiredService<ITenantContext>());
+
+        var organizations = services.GetRequiredService<IOrganizationWriteStore>();
+
+        // Refused: OrgA1 already exists under this tenant.
+        var refused = Organization.Create(
+            OrganizationId.From(SchemaFixture.OrgA1),
+            TenantId.From(SchemaFixture.TenantA),
+            "collides",
+            "Collides",
+            Clock,
+            UserId.SystemActor);
+
+        var conflict = async () => await organizations.AddAsync(refused);
+        await conflict.Should().ThrowAsync<AggregateConflictException>();
+
+        // The caller absorbs it and writes something else on the same context.
+        var accepted = Organization.Create(
+            OrganizationId.From(Guid.CreateVersion7()),
+            TenantId.From(SchemaFixture.TenantA),
+            $"after-{Guid.CreateVersion7():N}"[..20],
+            "After",
+            Clock,
+            UserId.SystemActor);
+
+        var second = async () => await organizations.AddAsync(accepted);
+
+        await second.Should().NotThrowAsync(
+            "the refused row was detached, so the second save carries only the new one");
+
+        await unitOfWork.RollbackAsync();
+    }
+
     // ── Harness ──────────────────────────────────────────────────────────────
 
     /// <summary>