fix(transform): make 95% emergency notification idempotent per compartment run

When pressure stays >=95% across multiple transform passes (force-cleanup usage
that keeps reporting 85k tokens), the same compartment run stays active for the
duration of historian execution. Without this guard each transform pass calls
sendIgnoredMessage, which uses session.prompt({noReply:true}). OpenCode persists
each such call as a USER message with finish=null in the session DB.

On the next loop iteration latest(msgs) returns the new notification-user as
lastUser (highest ID), making lastUser.id > lastAssistant.id. OpenCode's break
condition lastUser.id < lastAssistant.id stays false, so runLoop keeps calling
the LLM → mock returns 85k usage again → transform fires again → notification
fires again → infinite loop. We've observed this on CI with >1700 requests per
turn.

Add notificationSent on ActiveCompartmentRun and gate sendIgnoredMessage on it
inside transform-compartment-phase. The flag clears naturally when the run
completes via the activeRuns Map entry being deleted, so a future compartment
run can notify again.

Includes a regression test that:
- registers a never-resolving activeRun directly (no historian network paths)
- counts noReply user-messages via the client.session.prompt mock
- asserts the notification fires exactly once across three high-pressure passes
- avoids mock.module to keep test isolation across the suite

Verified with plugin/Pi/CLI suites + targeted local long-running e2e (10s pass).