fix: harden stat flush locking and request validation

[mjfelis]

Summary

Follow-up to #16, addressing 4 of the 5 hardening items tracked in #17. Compiles cleanly (./mvnw clean compile); no public REST contract change.

Changes

Request validation ordering (StatServerResource)

/stats/view and /stats/compare now validate from/to (and the other required fields) before calling computeGranularity, which dereferences both. Malformed requests now return 400 Bad Request instead of a 500 (NPE).

Defensive handling of concurrently-removed buckets (StatBuilderService)

Both flush methods now null-check the bucket fetched from the cache (it can be removed by a concurrent flush) and skip gracefully, instead of NPE-ing into a broad catch-all.

Stable locking around the periodic flush (StatBuilderService)

In the non-evict branch, the per-bucket lock is now held across the flush and the cache replacement (put). This closes the window where a concurrent increment could be applied to the pre-merge instance and then discarded when the merged instance overwrote it (lost update).

Consistent locking for on-demand flush (StatBuilderService)

flushStats(statClass, entityId) previously ran the flush under the dateStats monitor only. It now uses the same statLockObj → dateStats lock ordering as the periodic flush, so the two paths are mutually exclusive and consistent. Verified no code path acquires dateStats before a stat lock, so the ordering introduces no deadlock.

Not included

• Persistence-context / transaction boundaries (item 1 in Follow-up: thread-safety and robustness hardening in stat aggregation #17) intentionally deferred. Whether @Transactional is effective on the internally-invoked flush method depends on runtime behavior that needs a DB-backed test; changing commit semantics here without that is risky. Tracked in Follow-up: thread-safety and robustness hardening in stat aggregation #17.

Test plan

• ./mvnw clean compile passes.
• Lock-ordering reviewed: increments hold only the per-bucket lock; getStat holds dateStats but never acquires a stat lock inside it; flush now consistently takes statLockObj then dateStats.

Refs #17