Check execution conditions during updates

[ali-khokhar-nvidia]

Fixes #11711.

What changed?

SQL execution updates now use an optional SQL-plugin capability to include the expected prior record version or next event ID in the UPDATE predicate. A successful update on PostgreSQL, MySQL, or SQLite therefore acquires the row lock and validates the condition in one statement. When the conditional update affects zero rows, the existing lock/read path still resolves the precise condition error.

The existing HistoryExecution.UpdateExecutions contract remains unchanged. SQL plugins that do not implement the optional conditional updater continue to use the existing lock/check followed by update path.

Why?

Successful workflow mutations currently execute SELECT ... FOR UPDATE and then an unconditional UPDATE of the same execution row. Folding the existing condition into the update removes one persistence statement from every successful mutation on plugins that support it, without weakening optimistic concurrency or changing conflict details.

How did you test it?

• built
• run locally and tested manually
• covered by existing tests
• added new unit test(s)
• added new functional test(s)
• added new persistence integration test(s)

go test ./common/persistence/sql ./common/persistence/sql/sqlplugin ./common/persistence/sql/sqlplugin/mysql ./common/persistence/sql/sqlplugin/postgresql ./common/persistence/sql/sqlplugin/sqlite ./common/persistence/sql/sqlplugin/tests -run '^$' -count=1
go test ./common/persistence/tests -run '^TestSQLite(HistoryExecutionSuite|ExecutionMutableStateStoreSuite)$' -count=1
go test ./common/persistence/tests -run '^Test(PQ|PGX)$/^TestPostgreSQL(HistoryExecutionSuite|ExecutionMutableStateStoreSuite)$' -count=1

The added SQL-plugin cases cover both legacy next-event-ID conditions and record-version conditions, including mismatches that leave the stored row unchanged. A downstream compatibility probe also verifies that an implementation of the existing HistoryExecution.UpdateExecutions signature still satisfies the interface.

Potential risks

The optimized built-in path no longer performs the preliminary lock query. Its conditional update holds the same row lock through the transaction, while conflicts retain the existing typed condition errors through the fallback read. Plugins without the optional capability preserve the previous lock-then-update behavior.