feat: optimistic concurrency for UserStore.UpdateAsync (#70)

[andregoepel]

Fixes #70 (the deferred field-level concurrency follow-up).

Problem

UpdateAsync appends a full-state UserUpdated from the caller's snapshot. If a change committed after the caller loaded, this write silently reverts it — e.g. a user enables 2FA while a profile edit (loaded a moment earlier) is in flight; the profile save writes TwoFactorEnabled = false and 2FA is quietly turned back off. The earlier PR serialized the read-modify-write under the exclusive stream lock, but that alone can't tell a stale snapshot from an intended change.

Why not just use the stream version

A raw Marten stream version advances on every event, including the auto-managed lockout increments. Using it as the concurrency token would reject a profile update that merely raced a failed-login count — regressing the deliberate "merge lockout forward" behavior (and its test UpdateAsync_DoesNotRegressConcurrentlyChangedLockoutState).

Approach — a content-version token

• User.ContentVersion (new) is advanced by the projection on every content-changing event (UserUpdated not marked lockout-only, and UserRestored).
• UserUpdated gains a LockoutOnly flag that PersistLockoutStateAsync sets, so lockout increments do not bump the content version.
• UpdateAsync, under the exclusive lock, compares the caller's ContentVersion to the committed one; if it advanced, the snapshot is stale → return IdentityResult.Failed with code ConcurrencyFailure instead of clobbering. Lockout counters are still merged forward, so concurrent failed-login counting never causes a spurious conflict.
• After a successful write the in-memory ContentVersion is refreshed, so ASP.NET Identity flows that call UpdateAsync twice on the same instance (e.g. ResetAuthenticator: SetTwoFactorEnabledAsync then ResetAuthenticatorKeyAsync) keep working.

Compatibility

Existing projected docs (pre-ContentVersion) deserialize to 0 and self-heal on the next update; because both writers still go through AppendExclusive, concurrent updates are serialized and protected even across that 0 → 1 transition. A projection rebuild recomputes the token consistently.

Tests

New cases in UserStoreTests:

• stale snapshot → ConcurrencyFailure, first writer's change survives;
• stale profile edit does not clobber a concurrent 2FA enable;
• sequential updates on the same instance both succeed;
• a concurrent lockout increment is not treated as a conflict.

Existing coverage (lockout merge, security-stamp rotation, root invariants, the #70 no-lost-increments test) stays green. Full suite: 187 unit + 68 Blazor + 75 integration; build 0 warnings; CSharpier clean. THREAT-MODEL.md updated.