The store an owned model's routes are mounted over: the whole table, and the narrowing of it.
A Store[A] itself, so that Resource.routes keeps the one store parameter it has always had and the generated route table keeps the row it has always emitted. An owned model's routes are mounted by the same line as every other model's; the difference travels inside the value.
The owner's type is gone from the signature on purpose, and this is the one place in eezo where it is. It is Id[U] for every caller, U is known only where the model's own declaration is written, and nothing between that declaration and here needs to know it: the value that reaches by is the one Owned.currentUser read out of the request, and the function that consumes it is the one Scoped.apply closed over the matching io.eezo.core.OwnedStore. The two are built from the same declaration, so the cast inside apply cannot see a value of another type.
Public only because the generated route table has to name it, the same way InMemoryStore is. No user writes one.
The order is part of the contract rather than an implementation's habit, because a derived index renders it and a page that reshuffles itself on every write is a page nobody can read. Primary key rather than insertion, because insertion order is the one order a JDBC implementation cannot reproduce without a column invented to hold it, and a promise only one side can keep is not a seam.
Unit, not an outcome: every key a derived create inserts is an Id.gen() minted milliseconds earlier, so a taken key is unreachable and a conflict result would be a branch that can never be taken.
