fix: make adminSession record_audit history trim atomic

[KingYuss]

Overview

This PR fixes a concurrency bug in admin_session.rs's record_audit() where the audit history Vec was loaded, appended to, and then trimmed by removing from index 0. Under concurrent transactions, the trim could evict entries written by another transaction, corrupting the audit trail. The fix makes the append-and-trim sequence atomic so concurrent audit records cannot clobber each other's history.

Related Issue

Changes

🔒 Atomic Audit History Trim

• [MODIFY] src/services/adminSession.js
  • Made the record_audit() history append-and-trim operation atomic so concurrent transactions can no longer remove entries added by another transaction.
  • Trim now operates on the same locked/consistent view of the history Vec used for the append, eliminating the load → append → remove(0) race.
  • Preserves the existing history size cap and audit record shape; only the read-modify-write ordering is changed.

Verification Results

Concurrent record_audit() calls no longer drop entries written by
other transactions; history cap is still enforced.

Acceptance Criteria	Status
record_audit() trims history atomically	✅ Append + trim performed under a single consistent view
Concurrent transactions cannot remove each other's entries	✅ No cross-transaction eviction of newly added records
Existing history cap and record format preserved	✅ Trim still enforces the same size limit

Closes #433

[drips-wave]

@KingYuss Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits