Add track() API for custom event tracking

[timokoessler]

No description provided.

[aikido-pr-checks]

🟡 Medium - track() forwards attacker-triggerable custom events without any local throttling

This new API sends every custom event straight into the background process, but the only built-in rate limiter in the reporter applies to detected_attack events. If an application uses track() on a public flow such as failed logins, any client can trigger an unbounded number of IPC messages and queued events, and when the reporting API slows down or times out the unbounded background queue will grow in memory while the process serially retries each POST. That turns normal auth traffic or a brute-force attempt into a reliability issue for the protected service instead of just telemetry.

Show fix

Add local throttling or batching for custom events before they are enqueued, or extend the existing reporter-side rate limiting to cover custom events as well so public endpoints cannot generate unlimited background work.

_{More info - Reply on this comment to give feedback or ignore the issue.}

[aikido-pr-checks]

🟡 Medium - track() treats any leftover ContextVar value as an active HTTP request

track() only checks whether get_current_context() returns something, but the request hooks set that ContextVar and never clear it in production code. In async apps, background tasks created during a request inherit the current context, so a later track() call can still send the previous request's URL, IP address, and user even though it is no longer running inside that request. That breaks the documented contract for background jobs and can misattribute one user's event data to unrelated work.

Show fix

Clear current_context at the end of each request, or have track() verify that the context is still attached to an active request before extracting and reporting request/user data.

_{More info - Reply on this comment to give feedback or ignore the issue.}