docs: rewrite Concurrency Control as a learning guide

[khanaffan]

Summary

docs/learning/backend/ConcurrencyControl.md had drifted from the implementation — most visibly it told readers to call locks.acquireExclusiveLock / acquireSharedLock, which no longer exist on LockControl. This rewrites it as a learning document explaining how concurrency works when multiple users edit an iModel.

Every claim was verified against the current source: LockControl.ts, internal/ServerBasedLocks.ts, internal/NoLocks.ts, IModelDb.ts, Element.ts, Model.ts, ElementAspect.ts, EditTxn.ts, LocalHub.ts, and BackendHubAccess.ts.

What the doc now covers

• Policies — locking (default) vs noLocks, and the flow that selects ServerBasedLocks vs the no-op LockControl when a BriefcaseDb is opened.
• Editing lifecycle — pull → lock → change → save → push → release, as a sequence diagram.
• Acquiring locks — the all-or-nothing request, and the three failure modes learners routinely conflate: LockOwnedByAnotherBriefcase (contention), PullIsRequired (stale briefcase), and LockNotHeld (local edit-time check). Includes the per-lock freshness rules for shared vs exclusive acquisition.
• Ownership hierarchy — implicit downward locking and automatic upward shared locks on models/parents.
• Per-operation lock table — elements, aspects, models, changeElementParent, and changeElementModel (which requires exclusive locks on the entire moved subtree).
• Locks acquired automatically — newly created elements, owner locks, schema import, dropSchemas, profile/domain upgrade, and the exemption for indirect changes during ElementDrivesElement propagation.
• The Schema Lock — why it locks the whole iModel, plus the Schema Sync and semantic-rebase relaxations, and the fact that upgradeSchemas only takes the lock when a data transformation is required.
• Releasing locks — push/release/abandon semantics, and the beta Txn-level lock APIs used by undo/redo workflows.
• Local lock tracking — the locks / txn_locks / metadata tables and the Acquired / NewElement / Discovered origins.

Conflict-resolution details are deferred to PullMerge.md rather than duplicated (the old doc's conflict table had gone stale).

Notable corrections vs the old text

Old text	Reality
locks.acquireExclusiveLock(...) / acquireSharedLock(...)	locks.acquireLocks({ shared, exclusive })
—	pullChanges does not release locks; only push/explicit release does
"obtain the Schema Lock" before every import/upgrade	upgradeSchemas is optimistic, acquiring the schema lock only on DataTransformRequired; Schema Sync and semantic rebase further relax imports
Standalone optimistic conflict-resolution table	Deferred to PullMerge.md, which is the authoritative description

The #acquiring-locks-on-elements anchor is preserved, since BackendHubAccess.ts and IModelError.ts doc comments link to it.

Diagrams

Adds mermaid diagrams (matching the fence/style already used in Settings.md and Workspace.md), including sequence diagrams for the edit lifecycle, schema import, and two briefcases contending for the same element.

Testing

Docs-only change. Verified all relative links and heading anchors resolve, that every ($backend)/($common) symbol referenced exists and is public, and that code fences are balanced. No rush change file — no published package is affected.

[aruniverse]

is this a rewrite of #9645

[mergify]

This pull request is now in conflicts. Could you fix it @khanaffan? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

[khanaffan]

is this a rewrite of #9645

Its a complete rewrite but it includes what #9645 fixed which was incorrect method names used for exclusive and shared lock.