Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/executionplans/store_mongodb.go`:
- Around line 151-154: The MongoDB insert path currently returns immediately on
mongo.IsDuplicateKeyError(err), unlike PostgreSQL which retries; change the
insert logic in store_mongodb.go (the block that checks
mongo.IsDuplicateKeyError) to implement a retry loop (match PostgreSQL's
behavior) that attempts up to 5 retries on duplicate-key errors: on each retry
refresh/increment the plan version field used for the insert (same field used
when creating the document), re-attempt the insert, and only return the error
after exhausting retries or on non-duplicate errors; keep existing error
wrapping but preserve the duplicate-key detection using
mongo.IsDuplicateKeyError to trigger retries.
- Around line 115-155: The current sequence deactivates the old version with
s.collection.UpdateMany and then calls s.collection.InsertOne, which can leave
the scope without any active version if InsertOne fails; change to an
atomic-safe pattern: either wrap the deactivation and insertion in a MongoDB
session/transaction around the UpdateMany and InsertOne calls (use a
session.StartTransaction and CommitTransaction) or adopt the
insert-then-activate pattern—InsertOne the new mongoVersionDocument with
Active=false first, then perform a single BulkWrite that sets the new document
Active=true and old documents Active=false (or vice-versa) to guarantee the
swap; update error handling around mongo.IsDuplicateKeyError accordingly and
ensure Version/ mongoVersionDocument construction still uses the same fields
(ID, ScopeProvider, ScopeModel, ScopeKey, Version, Active, etc.).