Plugin StorageCollection needs a conditional put (D1-safe CAS, not Kysely transactions)

[saariuslystoned]

What we need

A durable conditional write on plugin StorageCollection (the get / put / query / delete API plugins use), equivalent in spirit to content _rev, and actually enforced in the write.

Today StorageCollection.put(id, data) is a blind overwrite. There is no expected-revision argument, no UPDATE … WHERE rev = ?, and no way to couple two collections in one durable step. Content entries already have _rev (#2782, #2121). Plugin storage does not.

Why this is not “wrap it in a transaction”

We hit this on Cloudflare / D1. Interactive Kysely transactions are unavailable there; PR #1394 is about isolating that fallback, not adding CAS. PR #3384 is the D1-safe pattern we actually need: a single conditional SQL statement (INSERT … WHERE NOT EXISTS), not db.transaction().

Concrete miss

A commerce catalog item has to flip managed (Inventory owns the count) vs unmanaged (manual availability) and release a registration claim in another collection.

With independent get then put:

1. Configure Inventory reads a revision, then unconditional put. A disable that commits in that gap is overwritten; the owner’s explicit “don’t manage stock” comes back as managed with an Inventory link.
2. Disable puts unmanaged, then deletes the claim. If the delete fails, the item is already unmanaged and the old claim remains; the next enable gets already-claimed.

Source-level repro and the two P1s: dinkuskit/commerce#17 (ClawSweeper review on 0ecc152). We are not merging that contract until this primitive exists. We are not asking EmDash to take that commerce PR.

Ask

One of:

1. put with an expected revision (or putIf) that becomes a conditional UPDATE / INSERT, 409/false on mismatch. Same idea as content _rev, but on StorageCollection and in the write, not only a preceding read.
2. Document that plugin collections are last-write-wins and will stay that way, so plugins stop promising concurrent-safe cross-collection transitions.

(1) is the useful one for shop-owner toggles that must survive a concurrent Configure Inventory persist.

Happy to follow with a PR after this is approved. Feature PRs without that stay closed; we will not open one first.

[saariuslystoned]

Closing as outdated: I missed merged PR #2980. The exact emdash@0.40.1 release already exposes getVersioned, compareAndSet, and compareAndDelete on plugin StorageCollection and KV. Verified in release source: https://github.com/emdash-cms/emdash/blob/emdash%400.40.1/packages/core/src/plugins/types.ts#L242-L256 and documentation: https://github.com/emdash-cms/emdash/blob/emdash%400.40.1/docs/src/content/docs/plugins/creating-plugins/storage.mdx#L111-L151 . This is a source/documentation check, not a new runtime reproduction.

These operations are atomic for one key, not two records or external actions. Our remaining catalog-transition/registration-claim concern needs evaluation against the existing API and our integration; closing this does not claim the DinkusKit cross-record workflow is fixed. Thanks to the contributors who already shipped this, and sorry for the duplicate ask.