RERUM memory grows unbounded

[thehabes]

Observed growing from ~100MB to ~350MB across sustained testing, only dropping after pm2 restart. Not sure if this is environmental, related to pm2, or caused by the code itself.

[thehabes]

Load Test Evidence (Run 4, multiple phases)

Memory observations across the test run (4 RERUM workers in PM2 cluster mode):

Point in time	Memory per worker
Fresh restart	~62MB
After Phase 2 (20 VUs, 13 min)	~82MB each
After Phase 9 DDoS (528K reqs)	147-276MB (uneven across workers)
After Phase 10 cascade	88-110MB (after partial restart)

Key observations:

• Memory grows monotonically under load — it never decreases without a restart
• Growth is uneven across cluster workers (one reached 276MB while another was at 147MB)
• Unlike TPEN Services, RERUM has no PM2 --max-memory-restart configured. TPEN Services caps at 500MB and auto-restarts; RERUM workers would grow until the OS kills them
• The deep cloning pattern (JSON.parse(JSON.stringify())) in configureRerumOptions, putUpdate, patchUpdate etc. likely contributes — each write creates 2-4x copies of the object in memory

Recommendation: At minimum, add --max-memory-restart 500M to the PM2 config for rerum_v1 to match TPEN Services. Long-term, investigate the deep cloning and unbounded query patterns.

[cubap]

Issue #251 indicates monotonic worker memory growth under sustained load. This PR now bounds query/search pagination via centralized getPagination() (default cap: limit<=500, skip<=100000) and reduces clone churn in hot utility paths. Operational follow-up: configure PM2 with max_memory_restart (for example 500M) for rerum_v1 to prevent unbounded resident growth between deploys/restarts.