Replace in-memory stores with persistent/distributed storage for multi-instance deployment compatibility

Summary

Several components use isolated in-memory maps as runtime stores. These stores are not suitable for production multi-instance deployments because:

• All state is lost on service restart
• State is not shared across instances (horizontal scaling breaks job polling)
• Stores grow unboundedly over time (memory exhaustion risk)

This issue was identified during code review of PR #256 (comment: https://github.com/wso2/reference-implementation-cms0057f/pull/256#discussion_r2928512908), requested by @anjuchamantha.

Affected In-Memory Stores

Recommended Actions

1. Short-term: Ensure TTL-based eviction is consistently applied to all job stores (currently partially implemented in bulk_member_match.bal and davinci_data_export.bal, but not in consentStore or the file-service/bulk-export-client stores).
2. Medium-term: Add a maximum capacity guard with eviction of oldest/failed entries before inserting new ones.
3. Long-term: Replace in-memory maps with a persistent store (e.g., a database) or a distributed cache (e.g., Redis) to support multi-instance deployments and survive restarts.

References

• PR #256: https://github.com/wso2/reference-implementation-cms0057f/pull/256
• Review comment: https://github.com/wso2/reference-implementation-cms0057f/pull/256#discussion_r2928512908

Start with the five listed files and compare the existing TTL handling in bulk_member_match.bal and davinci_data_export.bal with the other stores. Trace how each job, consent, and export store is written and read, then review PR #256 and its discussion for context. Done means the affected state is no longer dependent on isolated in-memory maps and supports the stated restart and multi-instance requirements.