fix(identity): reject stale profile updates with ETag/If-Match instead of losing the write

[marcelo-maciel]

What

PUT /identity/profile is a full-representation update with no concurrency token, so two
overlapping self-updates silently lose one another's changes (#1359). This adds an optimistic
precondition: GET /identity/profile returns a strong ETag, PUT honours If-Match, and a
stale token is answered with 412 Precondition Failed instead of overwriting the newer write.

Closes #1359.

The token is already there — no migration

The issue's own suggested fix proposed a new RowVersion/xmin column. That isn't needed:
AspNetUsers.ConcurrencyStamp is already mapped IsConcurrencyToken() in the snapshot, and
ASP.NET Identity's UserStore.UpdateAsync rotates it on every write. It can serve as the
validator directly, which keeps this change at zero schema impact and avoids carrying two
concurrency tokens on one entity.

The stamp is exposed as the ETag and never as a body field ([JsonIgnore] on
UserDto.ConcurrencyStamp), so it stays out of the OpenAPI contract and cannot be spoofed
through the request body.

Behaviour

Request	Result
No If-Match	Accepted, as before. Backward compatible.
If-Match matching the stored stamp	Accepted; the stamp rotates.
If-Match: *	Accepted (RFC 9110: matches any current representation).
Stale If-Match	412, nothing written.
Weak validator (W/"...")	412 — If-Match mandates the strong comparison function.
Malformed header	400, not 412: a 412 would send a well-behaved client into a refetch-and-retry loop it can never win, since the malformed header is its own bug.

Two smaller fixes fell out of this:

• UserManager.UpdateAsync answers a lost race with IdentityResult.Failed(ConcurrencyFailure())
  rather than throwing, so it used to surface as a generic 500. It now maps to the same 412.
• RefreshSignInAsync ran before the success check, refreshing the sign-in even when the update
  had failed. It now runs only on success.

Ordering matters

The precondition is checked immediately after FindByIdAsync, ahead of the storage calls and
ahead of SetPhoneNumberAsync. Anywhere later and a 412 would already have orphaned an upload,
or — on the deleteCurrentImage path — deleted the avatar with no database change to show for it.
UpdateProfile_Should_KeepAvatar_When_IfMatchIsStaleAndDeleteCurrentImageRequested covers exactly
that; I confirmed it goes red if the guard is moved down.

Worth naming for reviewers: SetPhoneNumberAsync is a second database write and its
IdentityResult is discarded (pre-existing, untouched here). The handler is therefore not atomic
across the two writes. A phone-number race is still reported, because the subsequent UpdateAsync
also fails and that failure now maps to 412 — but the mechanism is that mapping, not atomicity.

Client

clients/dashboard reads the ETag from the profile fetch, echoes it as If-Match on save, and
retries once on 412 against a fresh read. The retry is deliberate: the stamp also rotates on
writes the user never perceives as a profile edit (a password change, a failed sign-in, a new
avatar), so a single 412 should resolve itself rather than surface as a failed save.

clients/admin has no PUT /identity/profile caller on main, so nothing to change there. (The
issue text claims both apps write the profile — that part of my own report was wrong.)

The CORS piece — why this PR touches BuildingBlocks

An ETag/If-Match contract is a no-op in the browser unless CORS cooperates, and it did not:

• ETag is not a CORS-safelisted response header. FSH.Framework.Web.Cors never called
  WithExposedHeaders, so a browser hid the tag from JS on every cross-origin call — which is
  every dev run, since both React apps point apiBase at the API's own origin. The client then
  read null, stopped sending If-Match, and the endpoint degraded straight back to the lost
  update it now prevents. One WithExposedHeaders call (plus a four-line comment), placed after the
  branch so it covers both policies — neither AllowAnyHeader nor WithHeaders implies exposure.
• if-match is not a safelisted request header either. It joins AllowedHeaders in both
  shipped appsettings, otherwise AllowAll: false strips the precondition before the endpoint
  sees it.

I know src/BuildingBlocks is protected, so this is deliberately the smallest possible change and
kept in its own commit (feat(cors): expose ETag and allow If-Match…) — easy to drop or rework
without touching the rest. Happy to split it into its own PR if you'd rather review it separately.

Both directions are gated rather than described in a comment: CorsPolicyTests asserts the exposure
at the policy level for both branches, and
GetProfile_Should_ExposeETagToCrossOriginCallers_When_ProfileIsRead asserts it end to end against
a cross-origin request. The front-end specs mock the header, so without a server-side gate nothing
would notice the policy dropping it. Verified by mutation: removing the argument turns all three
red.

Separately and not fixed here: the tenant header both front-ends send on every request is
also missing from AllowedHeaders, so anyone enabling the restricted policy today is already
broken. Filed as #1367 rather than folded into this one.

Also in this PR

Directory.Packages.props pins SSH.NET to 2026.0.0 (cherry-picked byte-identical from #1333):
NU1903 breaks restore on main too, so nothing builds without it. Drop that commit once #1333
merges.

Verification

• Integration suite (Testcontainers): 756 passed / 1 skipped (pre-existing) / 0 failed
• All 13 other test projects green, aggregate exit 0 (~1057 tests)
• clients/dashboard Playwright: 152 passed; tsc -b clean and eslint . exit 0 (12 pre-existing
  react-refresh warnings, none in touched files)
• Mutation-checked at three points: reverting the precondition guard to a no-op turns 4 tests red;
  moving it below the storage calls turns the avatar test red; dropping the CORS exposure turns
  the three new CORS gates red.

Docs + changelog in fullstackhero/docs follow in a companion PR.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[marcelo-maciel]

CI note: the analyze (CodeQL) check is red for a platform reason, not a finding. GitHub is in a
partial outage right now (incident opened 2026-08-17 13:40 UTC) and the job died uploading its
results, after every query had already been interpreted:

##[error]No server is currently available to service your request.
Uploading failed SARIF file ../codeql-failed-run.sarif
CodeQL job status was failure.

Everything else is green: Backend CI, Frontend CI, Unit Tests, Integration Tests, E2E (admin and
dashboard), both scaffold builds and the DbMigrator smoke — 14 success, 2 skipped (publish jobs).
A re-run of analyze once the outage clears should be enough; I don't have permission to trigger
one here.