fix: we should unspend transaction tx outputs when the tx spending it…

[andreabadesso]

Acceptance Criteria

• We should properly "unspend" utxos spent by voided transactions
• We should "unlock" utxos that are locked by a given txproposal in case this txproposal fails.
• We should properly recalculate wallet balances when a transaction is voided

IMPORTANT: In this PR we are (1) using a experimental docker image for the new tests and (2) skipping genesis address balance check

(1) This will be fixed when HathorNetwork/hathor-core#1392 is merged
(2) This is a race condition, tests pass when running individually, we must debug and fix it in a later PR

Checklist

• If you are requesting a merge into master, confirm this code is production-ready and can be included in future releases as soon as it gets merged
• Make sure either the unit tests and/or the QA tests are capable of testing the new features
• Make sure you do not include new dependencies in the project unless strictly necessary and do not include dev-dependencies as production ones. More dependencies increase the possibility of one of them being hijacked and affecting us.

[andreabadesso]

e6458b8 fixes an issue with the integration tests causing them to consistently fail when running all tests at once but to succeed when ran individually, here is a better explanation:

Problem: The SyncMachine context was being shared across all test instances, causing the LRU cache (txCache) to persist between tests. This led to the unchanged guard skipping genesis transactions in subsequent tests because they were already cached from previous tests.

Root Cause:

1. Test 1 processes genesis transaction -> stores it in LRU cache
2. Test 2 receives same genesis transaction -> unchanged guard finds it in cache -> skips processing
3. Result: genesis address has 0 balance instead of expected balance

Solution: Changed from shared context to dynamically created LRU cache per machine instance:

• Before: txCache: new LRU(TX_CACHE_SIZE) (shared)
• After: txCache: null -> initialized fresh in INITIALIZING state

More context on the unchanged guard:

This guard is a performance optimization that prevents redundant database operations by checking if transaction metadata has actually changed. It compares the cached hash of a transaction's metadata against the current event's metadata hash. If they match, the event is ignored since we've already processed this exact state.

The guard is designed to skip repeated VERTEX_METADATA_CHANGED events for transactions we've already seen - for example, if only the accumulated weight changes (which wallet-service doesn't track), we can safely ignore the event. However, when the cache persisted across tests, it incorrectly skipped legitimate first-time processing of genesis transactions in subsequent test scenarios.