Resolves #4320

Problem

A UserEdit document's edits array is unbounded, 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

• Targeted atomic updates instead of full-document replaces. UserEditRepository.Replace is removed; goal and step writes now use $push/$set on just the affected edits element.
• Server-side cap on edits. Appending a new edit uses $push + $slice: -UserEdit.MaxEdits, so the array is atomically trimmed to the most recent MaxEdits entries on every append. Growth is bounded going forward.
• MaxEdits = 250: production documents that hit the limit held 387–976 edits at 14–16 MB (up to ~40 kB per edit), so 250 keeps worst-case documents around 10 MB. Value is easy to tune if we want to keep more history.

Because the capped $push produces a smaller resulting document, deploying this backend also unblocks already-affected users on their next goal write — the migration below is still needed to shrink oversized documents proactively (they slow down reads such as GetProjectUserEdits).

Frontend requires no changes: edits are addressed by GUID everywhere; nothing persists an index into the edits array.

Mongo migration instructions

database/trim-user-edits.js trims every UserEdit document with more than 250 edits down to its most recent 250, in place (documents are never deleted — each user's workedProjects references the document _id). Run it once against production (and qa) after this PR is deployed:

1. Back up first — trimmed entries are unrecoverable without a backup:

   # full backup via the maintenance pod, or at minimum:
   mongodump --db=CombineDatabase --collection=UserEditsCollection

2. Run the script on the database pod:

   kubectl -n thecombine cp database/trim-user-edits.js <database-pod>:/tmp/trim-user-edits.js
   kubectl -n thecombine exec <database-pod> -- mongosh CombineDatabase /tmp/trim-user-edits.js

   The script prints each affected document (_id, project, edit count, size) before trimming and verifies afterward that no document exceeds the cap.

3. Per the precedent of the GUID-subtype migration (Migrate MongoDB GUIDs from subtype 3 to 4 #4179 / Remove one-shot db guid migration script #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: 1186/1186 passed, including 12 new UserEditRepositoryTests integration tests that run the new atomic updates against a real (ephemeral) mongod — append, cap-trim (oldest dropped, newest last), replace-by-guid, step append/overwrite, and false-on-missing cases — plus a controller-level trim test via the mock.
• npm run fmt-backend: clean.
• Step writes previously stamped Edit.Modified; the new $push/$set updates preserve that (the goal history UI displays it).

Notes for reviewers

• Replace had no callers outside UserEditService, so it was removed from IUserEditRepository, the repository, and the mock rather than left as dead code that reintroduces the full-document-rewrite pattern.
• Each Edit.changes blob is still unbounded (a single huge edit could in theory exceed limits on its own); trimming what's stored per edit and/or moving edits to their own collection remain the longer-term options discussed in UserEdit document can exceed MongoDB's 16 MB limit, permanently blocking goal/step writes #4320.

This change is