Move attack wave detection to WebResponseCollector to capture user info

[PopoviciMarian]

Moved AttackWaveDetectorStore.check() from WebRequestCollector to WebResponseCollector. WebResponseCollector runs after the request completes, ensuring SetUser.setUser() has already been called and user data is available in the context.

[aikido-pr-checks]

Calling shared/static stores (AttackWaveDetectorStore.check, AttackQueue.add, StatisticsStore.incrementAttackWavesDetected) from concurrent request threads may introduce race conditions if those stores are not thread-safe.

Details

✨ AI Reasoning
​​1) The new code invokes shared/static stores: AttackWaveDetectorStore.check(context), AttackQueue.add(...), and StatisticsStore.incrementAttackWavesDetected() from a static reporter that can run concurrently across requests.
​2) If these store methods access or mutate shared state without internal synchronization or using concurrent-safe data structures, this introduces potential race conditions (check-then-act, concurrent modifications) that can cause data races or lost updates.
​3) This harms maintainability and correctness in a multithreaded web server context because the reporter runs on request-completion threads; ensuring atomicity or using thread-safe APIs is necessary. Therefore this change introduces potential thread-safety issues at the call site.

🔧 How do I fix it?
Use locks, concurrent collections, or atomic operations when accessing shared mutable state. Avoid modifying collections during iteration. Use proper synchronization primitives like mutex, lock, or thread-safe data structures.

_{More info - Comment @AikidoSec feedback: [FEEDBACK] to get better review comments in the future.}