MemoryStore should evict claims once their challenge expires

Esamina l’interfaccia Store e l’implementazione di MemoryStore, quindi segui TempoChargeIntent.matchTransferLogs e il relativo flusso di challenge verificato. Verifica come i memo delle transazioni possano associare un pagamento a un solo challenge prima di modificare la gestione dei claim. Il lavoro è completato quando i claim scaduti possono essere eliminati senza consentire attacchi di replay, mantenendo coerenti l’interfaccia e il flusso di pagamento.

Bind replay claims to challenge expiry. Ex. tryClaim(key, expiresAt).

Background

Store.tryClaim(key) (added in #24) retains transaction-hash claims forever. Every verified payment leaves a permanent entry, so any durable store grows without bound.

The typescript mppx SDK solved this by storing a marker that lapses at the challenge's expiry. One a challenge has expired, there's no reason to keep a cache entry for its associated transaction as it can no longer be claimed by an agent.

Using an expiry/TTL is safe in the typescript SDK because it cryptographically binds on-chain transaction memos to to a specific challenge. Therefore, a settled transaction can only satisfy exactly one challenge.

The mpp-java SDK has no such binding. TempoChargeIntent.matchTransferLogs compares only
currency, recipient, amount, and sender. Adding claim expiry would be a regression and make servers susceptible to replay attacks.

Proposed change

Implement memo binding between on-chain transactions and challenges. Then, once memo binding is in place, update the Store interface:

@FunctionalInterface
public interface Store {
    boolean tryClaim(String key);

    /** Claims {@code key} until {@code expiresAt}, after which the claim may be dropped. */
    default boolean tryClaim(String key, Instant expiresAt) {
        return tryClaim(key);
    }
}

TempoChargeIntent should pass the verified challenge's expires as expiresAt.

Why?

• Prevents unbound growth in MemoryStore
• Achieves parity with other SDKs