Re-applying a seed should add the fields an existing collection is missing, without rewriting what's there

[itaides]

Problem

A seed is how a site's schema lives in its repository, but it can only create a schema, not evolve one. Once a collection exists, there is no onConflict mode that adds a field the seed has gained since:

• skip (the default) skips an existing collection whole, fields included (packages/core/src/seed/apply.ts, the // skip branch: result.fields.skipped += collection.fields.length).
• update does add the new field, but it also rewrites the collection's settings (label, supports, urlPattern, admin, …) and upserts every existing field from the seed, so anything changed in the admin since is overwritten.
• error refuses.

So a field added to seed.json reaches a fresh install and nothing else. Every existing database, local or deployed, has to get it some other way.

Use case

A content site (ours is kukutrip.co.il, about 700 entries, Workers + D1) whose schema grows with the code: a new optional field on events, a new reference field bound to a relation. The seed is the reviewed source of truth, and we want emdash seed on an existing database to mean "bring the schema up to this", the way a migration does.

What it cost us: dev ran for days without two event fields (registration_deadline, registration_extras), because the deployed database had only ever received a full export, and nothing reported the drift.

Current workarounds

Two scripts that reach into EmDash's internals:

1. Locally, two passes of applySeed: skip over the whole seed for new collections and relations, then update over a seed cut down to just the fields _emdash_fields lacks. That's the only path that binds a new reference field to its relation. It still rewrites those collections' settings.
2. For D1, a script that diffs _emdash_fields against the local database and writes the ALTER TABLE ec_<collection> ADD COLUMN plus the registry row by hand (and the _emdash_relations row first, for a reference field, which has no column).

Both depend on table layouts that aren't a public contract.

What we'd suggest: an additive mode, say onConflict: "add" / --on-conflict add. It creates what's missing (collections, fields, relations, taxonomies) and leaves every existing row untouched. It also reports, rather than applies, any difference on an existing field (type, required). That makes re-seeding safe to run on every deploy.

Related: #3178 (relaxing required through updateField); Ideas: "emdash seed against the configured database and storage" (posted alongside this one).

Your involvement

• I am requesting this capability.
• I am offering to champion the design in a feature plan or RFC.
• I am offering to implement it after the design is accepted.