feat: stamperstore high disk usage

[martinconic]

Checklist

• I have read the coding guide.
• My change requires a documentation update, and I have done it.
• I have added tests to cover my changes.
• I have filled out the description and linked the related issues.

Description

Resolves #4884

This PR addresses extreme LevelDB I/O bottlenecks and CPU serialization overhead encountered during massive high-frequency chunk uploads.

The Problem

Under a load of hundreds of thousands of concurrent chunks, the node suffered from performance degradation across two distinct vectors:

1. LevelDB Put Lock Saturation: Writing a stamp item for every chunk requires locking LevelDB. Under 1M concurrent pushsyncs, this sequentially locked the disk queue, choking disk writes up to >100MB/s and stalling the networking routines for >140 seconds cumulatively on CPU profiles.
2. JSON Deserialization Overhead: Updating peer and surplus balances required fetching extensive math objects from the statestore. The unoptimized branch utilized JSON unmarshal to decode these values from ASCII text. Under heavy load, the CPU burned >20 seconds of pure flat execution time just parsing strings.

The Solution

1. StamperStoreCache (Debounced Async Writes)
   • Wrapped the Stamper Store in a highly concurrent memory cache.
   • Network routines now instantly write payloads to a thread-safe map in RAM.
   • A background flush loop sweeps the map every 5 seconds, writing thousands of items into LevelDB in a single, atomic batch. Disk churn drops massively, and the master process is completely freed from I/O wait times.
2. Binary BigInt Encoding
   • Implemented binary marshaling natively onto the central BigInt struct.
   • Refactored all accounting database getters/setters to utilize raw binary memory allocations instead of strings.
   • Included a silent fallback mechanism: the binary unmarshaler seamlessly parses older JSON-encoded database values so upgrades require no explicit database migration.