fix(lock): valid lock types and modernize locking providers

[joshtrichards]

• Resolves: #

NOTE: #62374 is a dependency for this PR; review/merge that one first then rebase this one

Summary

• Simplify and clarify shared-lock bookkeeping in DBLockingProvider.
• Improve readability of database query construction and lock lifecycle comments.
• Replace Memcache’s exclusive-lock magic value with a named constant.
• Simplify Memcache TTL helper control flow and tidy the shared-lock TTL restoration behavior note.
• Validate supported lock types before either provider reads or mutates its backing store (note: depends on refactor(lock): simplify acquired lock tracking #62374)

Details

Both providers now explicitly accept only LOCK_SHARED and LOCK_EXCLUSIVE. Previously, an invalid value passed to acquireLock() could follow the exclusive-acquisition path before request-local lock tracking occurred. The validation is performed before backend mutation, preventing an untracked lock from being created.

The DB provider retains its existing per-request shared-lock reuse behavior: a shared database lock may remain after it is released from active request bookkeeping and is cleaned up by releaseAll().

The Memcache provider retains its existing conditional TTL restoration logic. The cleanup makes the compare-and-set intent and the concurrent shared-lock failure mode easier to follow without changing its behavior.

Testing

• Existing LockingProvider contract tests cover shared/exclusive acquisition, release, conversion, and releaseAll() behavior through both concrete providers.
• Existing DB-specific tests cover cached shared-lock reuse and cleanup.
• Added invalid lock-type coverage in the shared contract suite

TODO

• Merge refactor(lock): simplify acquired lock tracking #62374
• Rebase after refactor(lock): simplify acquired lock tracking #62374 is merged

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI