Resolves #4320 (the "longer term" fix proposed there). Supersedes #4327.

Problem

A UserEdit document embeds its entire edits array, which grows without bound, and every goal/step write loaded the full document and rewrote it with ReplaceOneAsync. Once a document neared MongoDB's 16 MB limit, every write failed with WriteError 17419 and the user was permanently blocked from recording goal/step progress in that project (observed in production; see #4320).

Fix

Each Edit now lives in its own document in a new EditsCollection (StoredEdit: projectId, userEditId, plus the edit fields), and the UserEdit document's edits array holds only ObjectId refs, preserving order (StoredUserEdit). No document now grows meaningfully with use, so there is no cap on edit history.

• Goal/step writes are targeted atomic updates on the small per-edit documents; UserEditRepository.Replace (full-document rewrite) is removed.
• Appending a new edit inserts the StoredEdit and pushes its ref inside a multi-document transaction (the DB always runs as a replica set), so a failed append can't leave orphans.
• Reads assemble the wire UserEdit from both collections, so the API contract is unchanged — no frontend or OpenAPI changes.
• rm_project.py now also purges EditsCollection.

Mongo migration instructions (required)

database/migrate-useredits-to-edits-collection.js moves every embedded edit into EditsCollection, replaces each edits array with ordered refs (documents are modified in place — never deleted, since each user's workedProjects references the document _id), creates the { projectId, userEditId } index, and verifies that no old-format documents remain and every ref resolves. It is idempotent and safe to rerun.

This is a breaking schema change — old backends can't read migrated documents and the new backend can't read unmigrated ones — so it must be coordinated with the deploy:

1. Back up — e.g. maintenance/scripts/combine_backup.py, or at minimum mongodump --db=CombineDatabase --collection=UserEditsCollection.

2. Stop the backend (brief maintenance window), e.g. kubectl -n thecombine scale deployment backend --replicas=0.

3. Run the migration on the database pod:

   kubectl -n thecombine cp database/migrate-useredits-to-edits-collection.js <database-pod>:/tmp/migrate-useredits-to-edits-collection.js
   kubectl -n thecombine exec <database-pod> -- mongosh CombineDatabase /tmp/migrate-useredits-to-edits-collection.js

4. Deploy this version of the backend (which also restores the replica count).

5. If a pre-migration backup is ever restored later, rerun the script.

Per the precedent of the GUID-subtype migration (#4179 / #4209), the script can be removed from the repo in a follow-up once it has been run everywhere.

Testing

• dotnet build BackendFramework.sln: 0 warnings, 0 errors.
• dotnet test Backend.Tests: 1196/1196 passed, including 20 new UserEditRepositoryTests integration tests against a real (ephemeral) mongod replica set: create/read round-trip across both collections, assembly in ref order, transactional no-orphan behavior on failed appends, delete cascades, the targeted goal/step updates, and the atomic step bounds check (UpdateStepInEdit requires the target step to exist in its filter, so an out-of-bounds $set can't null-pad stepData).
• The repository integration fixtures now share one ephemeral mongod via a SetUpFixture; two runner instances in one test process caused intermittent MongoNotPrimaryException flakiness.
• Existing UserEditControllerTests pass unchanged, confirming the API behavior is untouched.
• The raw BSON layout is asserted in tests (the edits refs serialize as ObjectIds), so it matches what the migration script writes.
• npm run fmt-backend: clean.

Notes for reviewers

• Fresh installs get the EditsCollection index only via the migration script (the backend doesn't manage indexes anywhere today). The index is a perf optimization — correctness doesn't depend on it — but if we'd rather the backend ensure it at startup, that's a small follow-up.
• Already-affected production documents are fully unblocked by the migration itself; their whole history is preserved (nothing is trimmed).
• AddGoalToUserEdit now decides add-vs-replace from the atomic ReplaceEdit result instead of a prior read, and UpdateStepInEdit requires the target step to exist in its filter, so neither the goal write nor an out-of-bounds step write can corrupt data under concurrency. One pre-existing, low-risk race remains and is intentionally out of scope: UserEditController.UpdateUserEditStep still reads the step count to choose append-vs-overwrite, so concurrent step writes to the same goal could pick the wrong branch. Fixing it would require reshaping the wire contract (the client sends StepIndex ?? append), and the atomic bounds guard already rules out the only data-corruption outcome, so this is left for a follow-up.
• The EditsCollection index the migration creates is { projectId, userEditId, guid }, covering both the per-user-edit listing and the single-edit replace/step queries.

This change is