fix(rulemanager): scope monitorContainer exit to its own registration (#920)

monitorContainer re-derived liveness by polling rm.trackedContainers on a
5s ticker instead of listening for its own registration's removal. A
container removed and re-added faster than one tick left the stale
goroutine's poll seeing the ID "tracked again" (from the new Add), so it
never exited while ContainerCallback spawned a second monitorContainer for
the same ID -- leaking one goroutine per such cycle.

Each ContainerCallback Add now creates a done channel scoped to that
registration and passes it directly into monitorContainer, which blocks on
it instead of polling shared state. Remove closes and clears the current
registration's channel, so only the removal that owns a given goroutine can
stop it -- a re-Add's fresh channel has no effect on the old one.

Fixes #919


Claude-Session: https://claude.ai/code/session_01HS36ZHmKzkzibNi1oHVNUQ

Signed-off-by: Matthias Bertschy <matthias.bertschy@gmail.com>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>