Settings-backed stores lose concurrent updates #586

Every dashboard feature store keeps a whole JSON document in one settings key and mutates it read-then-write: auth:users, webhooks:subscriptions, webhooks:deliveries:<id>, and the overrides:* rows. Storage offers set_setting and nothing conditional, so two writers that read the same version both write, and the later write wins wholesale.

Concurrent writers are not hypothetical: the dashboard is meant to run as more than one replica against one backend, and #584 adds a standalone server that can run alongside an SDK dashboard on the same rows.

Raised in review on #584 (two findings, same root cause).

What it costs today

The affected writes are admin-frequency — creating a user, editing a webhook, setting an override — so the window is small and the blast radius is one lost edit rather than corruption. That is why #584 shipped without a fix rather than growing a locking scheme inside one crate.

What would fix it

A compare-and-set at the storage layer, e.g. set_setting_if(key, expected_version_or_value, new), with each backend implementing it natively:

• SQLite / Postgres: UPDATE … WHERE value = $expected, or a version column
• Redis: WATCH/MULTI, or a Lua script

The stores would then retry on conflict. Storage::acquire_lock exists and could serialise these writes instead, but it makes every settings write take a lock round-trip and leaves the lock's own TTL to reason about — worth comparing before choosing.

This is the "settings CAS" item already noted as core debt in the cross-SDK parity work; the SDK dashboards have the same pattern and would benefit from the same primitive.