Stratara.ServiceDefaults 3.1.3

• net10.0

  • Destructurama.Attributed (>= 5.3.0)
  • Microsoft.Extensions.Http.Resilience (>= 10.6.0)
  • Microsoft.Extensions.ServiceDiscovery (>= 10.6.0)
  • OpenTelemetry.Exporter.OpenTelemetryProtocol (>= 1.15.3)
  • OpenTelemetry.Extensions.Hosting (>= 1.15.3)
  • OpenTelemetry.Instrumentation.EntityFrameworkCore (>= 1.15.1-beta.1)
  • OpenTelemetry.Instrumentation.Http (>= 1.15.1)
  • OpenTelemetry.Instrumentation.Runtime (>= 1.15.1)
  • RabbitMQ.Client.OpenTelemetry (>= 1.0.0-rc.2)
  • Serilog.Extensions.Hosting (>= 10.0.0)
  • Serilog.Formatting.Compact (>= 3.0.0)
  • Serilog.Settings.Configuration (>= 10.0.0)
  • Serilog.Sinks.Async (>= 2.1.0)
  • Serilog.Sinks.Console (>= 6.1.1)
  • Serilog.Sinks.File (>= 7.0.0)
  • Serilog.Sinks.OpenTelemetry (>= 4.2.0)
  • Stratara.Shared (>= 3.1.3)

### Added

- **Mediator tenant-isolation behavior** (`Stratara.Mediator`) — `AddStrataraTenantIsolation()`
 registers a pipeline behavior that enforces tenant isolation at the mediator entrance, before the
 handler runs, for any request that opts in via the new `ITenantScopedRequest` marker
 (`Stratara.Abstractions.Multitenancy`). The behavior compares the request's `TenantId` (data owner)
 against the ambient session's data-owner tenant and rejects a mismatch with the new
 `TenantAccessDeniedException` (translated to HTTP 403 on ASP.NET hosts). `TenantIsolationMode.Default`
 enforces only the subject match (privileged cross-tenant operations pass when the endpoint promoted
 the session subject to the target); `TenantIsolationMode.Strict` additionally routes every
 cross-tenant operation through the new `ICrossTenantAuthorizer`, whose shipped default denies all
 cross-tenant access until a consumer registers its own authorizer. Complements the existing
 database-side `ApplyGlobalTenantQueryFilters` with a command-/query-entrance guard. New log-event
 IDs `114_101`/`114_102`/`114_003` in `Stratara.Diagnostics`.
- **`Stratara.Abstractions.Persistence.ConcurrencyConflictException`** — provider-agnostic
 wrapper for an optimistic-concurrency conflict detected during commit. Allows framework-level
 code in `Stratara.Projections` (and any consumer outside the `EntityFrameworkCore` package) to
 react to concurrency without taking an EF Core dependency. EF Core's `DbUpdateConcurrencyException`
 (and provider equivalents) flow through this type.

### Changed

- **`EfTransaction.SaveChangesAsync`** (in `Stratara.EventSourcing.EntityFrameworkCore`) now
 wraps `DbUpdateConcurrencyException` thrown by EF Core in the new
 `ConcurrencyConflictException`. PostgreSQL unique-violation paths remain on `DbUpdateException`
 (different semantics — duplicate-key on insert vs. stale-row on update/delete).
- **`EventSource.SaveChangesAsync`** (write-side append flow) extends its concurrency-handling
 catch to the new exception type so the existing append-conflict recovery path keeps working
 after the wrap. Behaviour for both EF concurrency conflicts and PostgreSQL unique violations
 is unchanged.

### Fixed

- **`TenantProjection` no longer aborts the event bundle on a parallel delete race.** The two
 delete handlers (`TenantDeleted`, `CustomerTenantsDeleted`) now swallow
 `ConcurrencyConflictException` silently — a missing row is the desired end-state of a delete.
 Before this fix, a consumer-side customer-delete cascade saga that emits both
 `CustomerTenantsDeleted` and a follow-up `TenantDeleted` for the same tenants would race the
 two parallel projection bundles on the same `TenantView` row; the loser threw
 `DbUpdateConcurrencyException` out of `SaveChangesAsync`, which propagated through
 `ProjectionWorker` and caused `RabbitMqBus` to roll back the entire bundle — including
 sibling projections that had already committed. Update handlers (rename / activate /
 deactivate / locale / customer-assigned) keep their current behaviour: a concurrency failure
 there is a real race that propagates.