fix: resolve race condition in update_from_tx (PM-19905)

[m2ux]

Summary

Fix a read-modify-write race condition in LedgerContext::update_from_tx where the ledger state is cloned outside the mutex then written back under a separate lock, enabling concurrent callers to overwrite each other's updates.

🎫 Ticket 📐 Engineering

---

Motivation

The tx_context function clones ledger_state under the mutex then immediately releases it. The subsequent update_from_tx modifies the clone and re-acquires the mutex to write back, creating a window where concurrent callers can clone the same baseline, compute divergent results, and overwrite each other. This was identified as Issue AJ in the Least Authority audit report (October 2025), rated Low severity but potentially causing lost updates, inconsistent SyntheticCost accumulation, and wallet/ledger divergence under concurrent toolkit usage.

---

Changes

Implementation (coming next):

• Restructure update_from_tx to acquire the ledger_state mutex at method entry and hold through write-back
• Replace self.tx_context() call with inline TransactionContext construction from the held guard
• Preserve tx_context() public method for backward compatibility
• Add concurrency test demonstrating proper serialization under parallel invocation

---

📌 Submission Checklist

• Changes are backward-compatible (or flagged if breaking)
• Pull request description explains why the change is needed
• Self-reviewed the diff
• I have included a change file, or skipped for this reason: [reason]
• If the changes introduce a new feature, I have bumped the node minor version
• Update documentation (if relevant)
• No new todos introduced

---

🔱 Fork Strategy

• Node Runtime Update
• Node Client Update
• Other
• N/A

---

🗹 TODO before merging

• Ready for review

[github-actions]

KICS version: v2.1.16

Category Results CRITICAL 0 HIGH 0 MEDIUM 96 LOW 12 INFO 83 TRACE 0 TOTAL 191	Metric Values Files scanned 31 Files parsed 31 Files failed to scan 0 Total executed queries 73 Queries failed to execute 0 Execution time 9