Flaky Registry Key Behaviour in Batch Test Involving Multiple CryptoUpdate Operations

**Description:**
There is a flaky registry key behaviour observed in a test that validates end-to-end atomic batch transactions with the following operations:
1. First batch transaction:
Auto-creates an account via NFT transfer to an alias.

2. Second batch transaction:
- Updates the account key to a new key.
- Updates it again back to the original key.
- Transfers a token from the account.
- Verifies the final key and token state.

**Problem:**
The test has shown flaky behaviour - the final assertion comparing the on-chain key to the expected key from the registry fails intermittently. This is caused by the fact that registry key entries for the alias do not always reflect the final account key, due to how keys are tracked during the batched execution.
As a workaround, a helper method syncRegistryKeyFromAccountInfo(...) was introduced to overwrite the key in the registry after execution, based on the actual on-chain state.
Temporary fix is introduced in the test to manually sync the key with the registry in order to ensure the test passes consistently, but the fix only masks the underlying issue with the registry state tracking that needs to be investigated.

**To Do (Investigation && Fix):**
- Investigate why registry keys are not consistently updated when multiple cryptoUpdate() operations are performed in the same batch transaction.
- Determine whether the registry's internal update logic fails to track the consecutive overwrites.
- Propose a solution to ensure the registry reflects the final state without requiring manual sync in the tests.
- Add coverage or logging to help debug the registry key mutations during batch execution, if possible.

**For Reference:**
File: AtomicBatchAutoAccountCreationEndToEndTests.java
Method: autoCreateAccountEditAccountKeyWithNewAndEditAgainWithOldKeysSuccessInBatch

Start in AtomicBatchAutoAccountCreationEndToEndTests.java at autoCreateAccountEditAccountKeyWithNewAndEditAgainWithOldKeysSuccessInBatch. Trace the consecutive cryptoUpdate() operations and the syncRegistryKeyFromAccountInfo(...) workaround to understand when registry keys are updated during batch execution. Done means the registry retains the final account key consistently and the test no longer needs manual synchronization.

Written by the indexing model from the issue text.