MariaDB write/write conflicts (ER_CHECKREAD) when saving a document are reported as an opaque Error number 3201

Problem

MariaDB 11.6.2 and later enable innodb_snapshot_isolation by default (MDEV-35124; the variable exists since 10.6.18 / 10.11.8 / 11.4.2). It adds write/write conflict detection to REPEATABLE READ: an UPDATE that tries to lock a row whose current version is not in the transaction's read view is refused with ER_CHECKREAD (error 1020, "Record has changed since last read") and the transaction is rolled back. The MariaDB documentation says such an error is to be treated the same way as a deadlock, i.e. retried.

XWiki does not handle it when saving a document:

• No retry, and no mapping to a dedicated error. The failure surfaces as XWikiException Error number 3201 ("Exception while saving document"), which tells an administrator nothing about what happened and is indistinguishable from a genuine save failure.
• The conflict window is as wide as possible: XWikiHibernateStore.saveXWikiDoc sets FlushMode.COMMIT (XWikiHibernateStore.java:569), so the UPDATE is only issued at commit time and the window covers the whole save (attachments, all xobjects, the archive rewrite), not a single statement.
• documentSavingLockMap (XWikiHibernateStore.java:534) does not help here: it serializes saves of the same document inside one JVM, whereas these conflicts are decided by the transactions' read views.

Before the setting existed, the same race was a silent lost update, so this is not a regression in XWiki - but it is newly visible, and any long operation that reads a document, does other work and saves it at the end is exposed when running on MariaDB 11.6.2 or later.

An occurrence in the wild: extension imports on extensions.xwiki.org fail on the first attempt and succeed when retried - XINFRA-496 for the server side, and the repository-specific race has its own issue.

Proposal

Recognise ER_CHECKREAD / HA_ERR_RECORD_CHANGED in the Hibernate store and either retry the transaction, as MariaDB recommends for deadlock-like errors, or throw a dedicated "document concurrently modified" exception, so that callers and administrators get an actionable error instead of Error number 3201.