fix: EventBucket.Wait() can return before a scheduled flush runs

[samyfodil]

What

scheduleFlush calls b.wg.Add(1) from inside the goroutine it spawns, instead of before starting it:

go func() {
    defer b.wg.Done()
    // ... flush logic
}()
b.wg.Add(1) // too late — Wait() may already be past wg.Wait()

sync.WaitGroup's contract requires Add to happen-before Wait observes the counter. Since Add(1) here runs from inside the new goroutine, there's a window where the goroutine hasn't been scheduled yet, the counter is still 0, and a concurrent call to Wait() returns immediately — before the flush has even been registered, let alone run.

Fix

Move wg.Add(1) to the caller side, before go func() { ... }().

Tests

Added TestBucketWaitBlocksUntilFlush, which fails consistently on the original code (Wait() returns having observed 0 flushes) and passes on the fix. Verified: fails 10/10 with -race -count=10 against the original bucket.go, passes 20/20 against the fix.

Also fixed a separate, pre-existing race in the existing TestBucket: it read TestFlusher.NumFlushes/FlushedEvents and bucket.bucket without synchronization while the flush goroutine concurrently wrote them. Added a mutex to TestFlusher and locked the reads. Unrelated to the wg.Add bug itself, just something -race surfaced while working in this file.

go build ./..., go vet ./..., and go test -race ./... are all clean on this branch.

Related to #176, which is a separate, deeper race in AdapterBase.Stop() found in the same file — this PR doesn't touch or fix that one.