Failed intents leave dependent intents blocked indefinitely

Nobody has claimed this yet.

## Problem

When a committor intent fails, later intents that depend on the same committed accounts can stay in `blocked_intents` forever. They never run, and callers waiting for their results never hear back.

## Reproduction

Schedule an intent that fails, followed by one that shares a committed key with it and also uses a second key. Then schedule another intent using that second key. After the first failure, inspect the blocked queue and result subscriptions: the dependency extends beyond intents that directly share the original key.

The scheduler cascade and execution-engine tests in #1524 cover this scenario in source.

## Expected

Fail the waiting dependents too, rather than executing work that relies on a failed intent. Remove them transitively from the blocked queue, report the original error for the failed intent, and send exactly one `PoisonedIntentError` for each removed successor—even when several dependency paths reach it. Unaffected predecessors and unrelated work can still run.

The failed intent's committed keys remain poisoned until the process restarts. Reject new intents touching those keys and poison every key in each rejected bundle.

There's an important difference for callers: already-scheduled successors receive failure results, but new intents rejected at admission receive **no result broadcast**. Callers must handle those paths differently.

Expose poisoned-key and cascade-size metrics so we can see how much work is affected.

## Context

The changes are in `magicblock-committor-service/src/intent_engine/intent_scheduler.rs` and `intent_execution_engine.rs` in #1524. Poison state is process-local; it doesn't survive a restart.