Fix deadlock in Manager.Stop/StopReaders

[theop-dd]

What does this PR do?

Split stopReaders() into 3 phases:

1. Close all reader file descriptors (under manager.stateLock) — signals goroutines to stop
2. Temporarily release manager.stateLock — lets handler callbacks complete, goroutines exit
3. Re-acquire manager.stateLock — clean up underlying maps
   stop() now sets m.state = reset before calling stopReaders() to prevent concurrent NewPerfRing/NewRingBuffer from adding readers during the unlock window.

Known limitations

• PerfMap.Stop() / RingBuffer.Stop() still hold their own stateLock during wgReader.Wait(). This is fine for current callers (only used for cleanup when Start() fails, so no goroutine is running). A warning comment documents the risk.
• StopReaders() does not set manager state during the unlock window, so a concurrent NewPerfRing call could theoretically slip through. This is documented as a usage error.

Motivation

Manager.Stop() and Manager.StopReaders() can deadlock when a handler callback (DataHandler, RecordHandler, etc.) calls Manager methods like GetMap() or GetProbe().
The deadlock occurs because:

1. Stop holds manager.stateLock (write lock) and waits for the reader goroutine to exit (wgReader.Wait())
2. The reader goroutine's handler needs manager.stateLock.RLock() to call Manager methods
   Neither can make progress → deadlock.
   This is a race condition: it only triggers if Stop takes the lock while a handler is mid-execution. In production it's masked by SIGKILL at shutdown, but it surfaces in tests that stop and restart the manager in the same process.

This deadlock occurs when we call Stop on the manager. We never saw it in prod when the agent runs because if it happens, the process is eventually killed. This was however causing incidents on CI, where the hang caused every subsequent test to time out.

[brycekahle]

It looks like this will fix StopReaders for now, but it appears any code which calls perf/ring Stop while holding the manager stateLock could continue to deadlock. I can explore how to fix that in a more permanent and less brittle way.

[theop-dd]

exactly @brycekahle , that's why I put a comment on top of the function.