Stratara.Infrastructure 4.0.2

• net10.0

  • Azure.Identity (>= 1.21.0)
  • Microsoft.AspNetCore.Http.Abstractions (>= 2.3.12)
  • Microsoft.Extensions.Configuration.Abstractions (>= 10.0.11)
  • Microsoft.Extensions.DependencyInjection (>= 10.0.11)
  • Microsoft.Extensions.Logging.Abstractions (>= 10.0.11)
  • Microsoft.Extensions.Options.ConfigurationExtensions (>= 10.0.11)
  • StackExchange.Redis (>= 3.1.31)
  • Stratara.Contracts (>= 4.0.2)
  • Stratara.EventSourcing.EntityFrameworkCore (>= 4.0.2)
  • Stratara.Mediator (>= 4.0.2)
  • Stratara.Outbox.RabbitMQ (>= 4.0.2)
  • Stratara.Security (>= 4.0.2)
  • Stratara.Sessions (>= 4.0.2)
  • Stratara.Shared (>= 4.0.2)

Two operational fixes, both found while a consumer rolled out bus-envelope signing and reasoned
about rebuilding its read models: a projection replay now survives a passing failure, and an
integrity failure says whether the signature was absent or wrong. Additive on every published
surface.

### Added

- **A projection replay retries a failing batch before it gives up.** Each batch — the read from
 the event store and the application of its entries — now runs under a new named policy,
 `ResilienceNames.ProjectionReplayBatch`: five attempts in all, exponential backoff from one second
 with jitter between them, any exception except cancellation. A read-store timeout or a
 dropped connection mid-rebuild no longer ends the replay; a failure that persists through every
 attempt ends it exactly as before, with the same failure record. A retried batch is applied
 again from its first entry in a fresh scope, which relies on the guarantee projections already
 give under at-least-once delivery: a second application converges (see *Write handlers that
 converge rather than accumulate* in the projection guide). Each failed attempt logs a new
 warning, `104_011`. `AddResiliencePipelines` registers six policies rather than five. Nothing
 about truncation, ordering, progress, the failure record or the lease changes.

### Changed

- **An integrity failure now says whether the signature was absent or wrong, and the existing
 warning and error ids fire only for a signature that is present and does not verify.** An
 unsigned envelope — what every not-yet-restarted publisher emits during a `Permissive` roll —
 was logged as *"signature mismatch"* under the same id as a key mismatch or tampering, so an
 operator could not tell a rolling restart from an attack without correlating host start times.
 Four new event ids carry the unsigned case: `105_004` (command, permissive), `111_004` (event
 bundle, permissive), `105_105` (command, strict) and `111_105` (event bundle, strict). The
 existing `105_003`, `111_003`, `105_104` and `111_104` keep their numbers and their level but
 now mean a present signature that did not verify; an alert keyed on one of them goes quiet
 during a roll instead of firing for every unsigned message. Strict-mode rejections name the
 case in their exception message. `BusEnvelopeIntegrityVerifier.Verify` gains an overload with
 `out BusEnvelopeIntegrityFailure` (`None`, `Absent`, `Invalid`); the existing overload and the
 `BusEnvelopeIntegrityResult` values are unchanged. An absent signature no longer reaches the
 signer, which already answered `false` for it.