Pre-commit OpenSearch indexing queue calls race / survive rollback

[JasonWildMe]

Problem

IndexingManager.addIndexingQueueEntry() at IndexingManager.java:57-80 immediately dispatches a worker that opens a new Shepherd and reads the target object by id. If the caller queues before committing its own transaction, two failure modes exist:

1. Race: the background worker reads state the caller has not yet committed, so the index reflects an older or partial version.
2. Rollback survival: if the caller rolls back, the index has still been updated — it now reflects data that was never persisted.

Known sites that queue pre-commit

• Encounter.processPatch() — queues inline; commit happens later in BaseObject.processPatch.
• MarkedIndividual.mergeIndividual() — queues both individuals; enclosing servlet MergeIndividual.java commits later.
• iaResultsSetID.jsp — all three branches queue before the final commit at line 352-354.

Recommended fix

• Encounter.processPatch(): move the queue call out of processPatch itself and into the afterPatchTransaction() hook (BaseObject.java:332-338) which runs post-commit-and-close. Only Encounter currently overrides that hook (Encounter.java:5345-5360).
• MarkedIndividual.mergeIndividual(): move the two addIndexingQueueEntry calls out of mergeIndividual and into the callers (MergeIndividual.java, ScheduledIndividualMerge.java), executed after the caller's commit.
• iaResultsSetID.jsp: move the queue calls below the final commitDBTransaction() at line 352.

Relation to #1514 and PR #1547

• individualNumberEncounters on encounter not reindex when the related MarkedIndividual's number encounters is changed #1514 (stale individualNumberEncounters on encounters) is being fixed in a separate PR that avoids introducing new pre-commit queueing but deliberately does not move these pre-existing pre-commit calls. This is the follow-up ticket tracking that cleanup.
• PR Fix OpenSearch index staleness when encounters assigned to individuals #1547 cherry-picked work that also queues post-commit at the right places in IndividualRemoveEncounter (correct) but inherits the pre-commit pattern at the sites above.

Severity

Medium. The race/rollback window is narrow (a single background task execution under the 4-thread indexing pool), and opensearchIndexDeep() reads encounters by id at index time so a rolled-back state is usually corrected by the next real mutation. Still, it produces intermittent index/DB divergence that's hard to diagnose.