[sadeqabuhattem]

Summary

Makes the EF Core capture safe beside another library's SaveChanges interceptor — such as
DotNetBoost.MultiLingual's — registered before it or after it, with or without a retrying strategy,
and fixes four bugs that show up with Auditing alone. This is the content of 1.0.0-preview.3; the
full list is in CHANGELOG.md under [Unreleased].

Commits

1. Let the engine build an entry without storing it, and report lost atomicity (Core, API).
   AuditRecorder.RecordAsync splits into Prepare and Counted; adds the lost-atomicity
   reporting API.
2. Make the EF Core capture safe beside another SaveChanges interceptor (the interceptor and
   every new test). The fixes and the redesign share the rewritten interceptor, so they are one
   commit.
3. Document sharing a DbContext with other SaveChanges interceptors (docs, changelog).

Each commit builds on its own.

What changes

Beside another interceptor, ported from MultiLingual's save lifecycle into
AuditingSaveChangesInterceptor.Lifecycle.cs:

• A save another interceptor issues from inside this one is nested. It joins the save in
  progress, and only the outermost save writes the deferred entries, commits or rolls back.
  Nested is decided by whether EF has already accepted the outer save's changes. Anything else
  starts over: a save abandoned when a later interceptor's SavingChanges threw, or one being
  replayed under a retrying strategy.
• With another interceptor registered after it, the capture commits from EF's
  DbContext.SavedChanges event, once every interceptor has finished, so their post-save work is
  inside the transaction.
• A transaction someone else committed early is detected before the deferred write.

Standalone fixes:

Was	Now
A cancelled save left the transaction open, and a retry recorded the creation twice	Rolled back, like a failure
A concurrency conflict left the transaction open	Rolled back from EF's DbContext.SaveChangesFailed event. A ROLLBACK in the ThrowingConcurrencyException hook itself fails on PostgreSQL and SQL Server, because the connection is still reading the batch
A creation inside a TransactionScope threw	Uses the ambient transaction
A save another interceptor suppressed was still captured	Not captured
A second context in one scope tracked its entries on the registered context, so they were never written	Entries go to the context being saved; a context without the audit tables is refused

Public API (additions only; the surface baselines are updated)

• AuditingBuilder.OnLostAtomicity(LostAtomicity) and AuditingOptions.OnLostAtomicity
• enum LostAtomicity { Report, Throw } in Core.Models
• IAuditObserver.AtomicityLost(string correlationId, int entries): a default interface member,
  so existing observers still compile. LoggingAuditObserver logs it as an error.
• AuditingTelemetry.AtomicityLost, the dotnetboost.auditing.atomicity.lost counter

Behaviour changes to look at

• The commit from EF's event is synchronous: one blocking round trip, even under
  SaveChangesAsync, and only when another SaveChanges interceptor follows this one.
• The capture no longer writes through IAuditStore.AppendAsync. It adds entries to the
  context being saved. A store wrapped to observe entries no longer sees the capture's.
  Explicit IAuditManager calls still go through the store.
• Rollbacks on failure paths are best-effort, so a broken connection cannot replace the
  exception that explains why the save failed.

Tests

New suites, run in both registration orders and through both SaveChanges and
SaveChangesAsync:

• TestSupport/CompositionInterceptors.cs: stand-ins for another library, without referencing
  one: a post-save writer committing in SavedChanges or from EF's event, a replaying interceptor
  under a retrying strategy with tracker restore, a later SavedChanges that throws, and others.
• ProviderTests/EfCoreCompositionTests.cs and EfCoreSaveLifecycleTests.cs on SQLite.
• IntegrationTests/CompositionTests.cs on PostgreSQL and SQL Server, standalone fixes included.

The targeted SQLite tests were written first and failed on preview.2. The engine tests use the new
API, so they did not compile against it.

Release, locally: UnitTests 189, ProviderTests 288, ApiTests 59, SurfaceTests 7 (each on net8.0
and net10.0), IntegrationTests 280. All pass. Restore passes with fresh vulnerability data, and the
Release build has 0 warnings.

Also checked against the real DotNetBoost.MultiLingual 1.0.0-preview.3, in an application with
Auditing registered first and database-generated keys:

• A forced failure in MultiLingual's translation write left the product and its Created entry
  committed on preview.2, and rolls back on this branch.
• With EnableRetryOnFailure, every change was recorded twice on preview.2, and once here.

Still open, documented in docs/limitations.md

• The deferred write is still a nested SaveChanges that other interceptors see. An interceptor
  sharing the context should count nested saves, as MultiLingual does.
• A throw from a later interceptor's SavingChanges leaves the transaction open until the
  context's next save, which cleans it up. EF gives no hook in between.
• An interceptor that reaches the context some other way than AddInterceptors can't be seen
  following this one.

MultiLingual rolls back inside ThrowingConcurrencyException too, so it probably has the same
real-engine bug fixed here. That's for a separate PR in its repository.

🤖 Generated with Claude Code