Batch FX lookups, guard subscription updates with a concurrency token

[rghvgrv]

The two design calls left open from the review. Branched from current main (ea7d9a1), so #139 is included.

Closes #137
Closes #138

#137 — one FX query instead of one per subscription

BurnRateCalculator called GetRateAsync per subscription, and FxRateService reads the cache with a fresh AsNoTracking query each time, so nothing deduplicated them. Twenty USD subscriptions against an INR home currency issued the same query twenty times — on the screen the app opens to, again on every SubscriptionsChangedMessage, against a 0.1 CPU instance and a scale-to-zero database.

IFxRateService gains GetRatesAsync: many base currencies, one target, one round trip (base_currency = ANY(...)). Absent from the returned dictionary means "no rate", exactly as null does for the single-pair call, so UnresolvedSubscriptionIds is unchanged.

I went with the batch method on the interface rather than memoizing inside FxRateService — memoization would have hidden the round trips rather than removed them, and left the interface implying a cost it no longer had.

Two behaviours deliberately kept: the on-demand fetch still runs for missed pairs only (a user's first subscription in a new currency must count before the next scheduled pass), and the target currency is dropped before querying since nothing stores an identity rate.

The calculator now walks the list twice, so it materializes rather than trusting the caller's IEnumerable — pinned by a test using a sequence that throws on second enumeration.

#138 — optimistic concurrency

Postgres' xmin mapped as a shadow row version. No column is added — xmin exists on every table, and Npgsql's generator emits no DDL for it. I verified with dotnet ef migrations script: the migration produces only the __EFMigrationsHistory insert. No backfill, no lock on an existing table. The generated C# reads as though it adds a column, so there's a comment on the file recording what the SQL actually is.

The token has to round-trip to be worth anything. Loading a row and saving it in the same call compares it with itself and can never conflict — so SubscriptionDto carries Version out and CreateSubscriptionRequest takes it back in, where it becomes the OriginalValue the UPDATE asserts on. This is the part that makes the feature real rather than decorative.

Version is optional, and that's a judgement call worth reviewing: APKs already sideloaded don't know the field and aren't force-upgraded, so omitting it keeps last-write-wins rather than failing every older client's save. New clients get the guarantee; old ones are no worse off than today. A test pins that path.

UpdateAsync now returns SubscriptionUpdateResult — null could no longer distinguish "no such subscription" from "someone got there first", and 404 and 409 are different answers.

Client behaviour is the one you picked: a 409 reloads the record and explains, without navigating away. Not a retry — a retry would re-apply an edit written against a state that no longer exists, which is the thing being prevented. Reloading also refreshes the version, so the next save isn't doomed to conflict again.

Testing

Suite	Result
SubVora.Api.Tests	129 passed
SubVora.Mobile.Tests	166 passed
SubVora.Infrastructure.Tests	103 passed
SubVora.Application.Tests	38 passed

436 total, 0 failures, run in full against real Postgres via Testcontainers.

New coverage worth calling out — ConcurrentUpdateTests reproduces the actual bug end to end: create → mark paid → save a stale edit → 409, and the payment survives with NextBillingDate and LastPaidDate intact. Before this change that request succeeded and reversed the payment. Also covered: stale-edit-vs-edit, no-version-still-applies, 404-not-409 for a missing row, and on the client, version round-trip, the 409 reload, no spurious SubscriptionsChangedMessage on a refused save, a fresh version on retry, and the reload-also-failed case keeping the offline message rather than claiming a reload happened.

Note

SubscriptionDto and CreateSubscriptionRequest changed on both sides — there's no shared DTO project by design, so API and mobile were edited together, per CLAUDE.md.