Add persistence layer for swapReputationScorer.js

[paul-motron]

Summary

swapReputationScorer.js computed reputation scores as a pure, in-memory calculation with no durable store — a score only existed for the duration of the call that produced it. This adds a persistence layer so scores survive process restarts.

Changes

• Documented the intended persistence backend directly in swapReputationScorer.js (see the new "Persistence — Issue Add persistence layer for swapReputationScorer.js #878" block at the top of the file).
• Added a small ReputationStore interface (get / set / getAll) so scoring logic stays decoupled from where scores live, with two implementations:
  • MemoryReputationStore — process-local Map, non-durable. Default for tests/short-lived scripts.
  • FileReputationStore — scores serialized to a JSON file on disk, durable across process restarts. Re-reads from disk on every call rather than caching in memory, so it stays correct if multiple short-lived processes share the same file.
• Added persistReputationScore(input, store, nowMs?) and getPersistedReputationScore(participantId, store), which wrap the existing pure calculateReputationScore — the scoring math itself is untouched.
• Added tests, including one that persists a score with one FileReputationStore instance and reads it back with a brand-new instance pointed at the same file (no shared in-memory state), simulating a process restart.

Design notes

This repo's JS side (src/) has no DB/cache infrastructure of its own — that only exists in the separate Rust api-server (api-server/src/cache.rs, which already reserves a reputation: key prefix, sourced today from the on-chain RPC client rather than this scorer). Given that, this PR keeps the persistence layer self-contained and backend-agnostic rather than reaching into the Rust service:

• FileReputationStore is the practical default for a single-instance deployment or tooling that doesn't have a DB handy.
• A production, multi-instance deployment should back the same three-method interface with the API server's shared Redis-backed cache or a DB table — nothing above this layer would need to change.

Closes #878

[drips-wave]

@paul-motron 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