fix(plugin-search): surface sync write errors that silently roll back the parent transaction

[eeshsaxena]

Fixes #17699.

Problem

syncDocAsSearchIndex runs the search-doc create/update/delete calls with the incoming req, so they join the parent operation's transaction. Every write is wrapped in a try/catch that logs and swallows the error. Under MongoDB, a failed write inside a transaction aborts the whole transaction, so the parent operation (e.g. a publish) rolls back — but because the error was swallowed, payload.create/payload.update and the REST/GraphQL request resolve as if they succeeded. The editor sees their publish silently revert to the previously published version, with the only signal being a server log line.

Fix

Errors from the search-doc writes are still logged, but they are now rethrown when both:

• the sync is running inside a shared transaction (req.transactionID is set), so a failed write has genuinely aborted the parent operation and reporting success would be wrong; and
• the caller has not opted into handling sync errors itself (onSyncError is not provided).

That second condition keeps the change scoped to the document-lifecycle hook path (the publish in the issue). The reindex handler passes its own onSyncError and manages its own transaction and per-collection recovery, so it stays best-effort exactly as before. When there is no shared transaction to abort (e.g. adapters running without one), the sync also stays best-effort and only logs.

A small WeakSet makes sure each error object is logged once, so an error rethrown out of an inner catch and re-caught by an outer one keeps its original, most specific message instead of being relabelled.

Result

For an indexed collection with a search-doc write failure inside the parent transaction, the parent operation now fails with the error surfaced to the caller instead of resolving successfully and silently reverting. The repro in test/plugin-search-write-errors (a second publish that hits a unique-index conflict on the search collection) now either surfaces the error or persists, rather than doing neither.