[core] Surface JDBC lock acquisition failures

[LuciferYang]

Purpose

AbstractDistributedLockDialect.lockAcquire caught every SQLException and returned false, meaning "lock not acquired". Real contention does surface as a primary-key constraint violation on the lock row, so false is correct there, but a non-contention error (a dead pooled connection, a missing distributed_locks table, access denied) was swallowed the same way: JdbcCatalogLock.lock() then busy-spins for the whole lock-acquire timeout re-issuing the same failing INSERT and finally throws a generic Acquire lock failed with time: ... that hides the cause.

This returns false only for a constraint violation (contention) and rethrows any other SQLException, so a non-retryable failure fails fast with its root cause and the operator can tell "someone else holds the lock" apart from "the lock table is gone". Contention is classified by SQLState 23xxx or SQLIntegrityConstraintViolationException, with a message-substring fallback for dialects that report neither (SQLite, where the fallback is load-bearing). The high-value errors this surfaces (connection reset, missing table, column overflow) do not contain the fallback substrings, so they are not reclassified as contention.

This closes #10271.

Tests

• testBrokenLockInsertSurfacesRootCause pins that a non-contention failure on the lock INSERT propagates instead of being retried for the full timeout.
• testAcquireLockFail continues to pin that real contention returns false and times out as before.

API and Format

No.

Documentation

No.