Avoid redundant oracle processing while a conflicting transaction is still pending

[mgpai22]

Summary

The chain-event processor continues running the full oracle cycle even when it already knows the next transaction will conflict with a still-pending transaction's inputs.

Observed behavior

After a transaction is submitted and still pending, the node repeatedly runs the full cycle:

• fetches oracle data items
• calculates trie operations
• uploads payload to cloud
• then logs tx inputs conflict with pending tx; skipping

The system is doing DB reads, trie diff calculation, and cloud upload work before short-circuiting on the known tx conflict.

Why this matters

• wastes oracle data source reads
• wastes CPU on trie diffing
• wastes cloud/IPFS upload calls
• creates noisy logs
• increases operational cost during pending-tx windows

Expected behavior

If the strategy can determine that required inputs are already locked by a pending tx, it should exit the cycle before expensive work starts.

Proposed behavior

• check for pending/conflicting tx status before upload/build work
• short-circuit the cycle immediately when conflict is known
• emit a single clear log line explaining the skip reason

Acceptance criteria

• no cloud upload occurs when a conflicting pending tx is detected
• no recreate tx is built when a conflicting pending tx is detected
• no diff work is performed after conflict is known
• logs clearly state the cycle was skipped due to pending tx conflict
• behavior remains safe against accidental double-spend / duplicate submission