feat: task pipeline-based architecture

[effie-ms]

Which Jira task is linked to this PR?

https://lifi.atlassian.net/browse/LF-17393

Why was it implemented this way?

executeStep() is refactored: now there is a single flow of tasks, and ecosystem packages implement only ecosystem-specific context and tasks themselves. Shared implementations of tasks are reused from the main SDK package.

Checklist before requesting a review

• I have performed a self-review and testing of my code.
• This pull request is focused and addresses a single problem.
• If this PR modifies the SDK API or adds new features that require documentation, I have updated the documentation in the public-docs repository.

[aikido-pr-checks]

TRANSACTION_HASH_OBSERVERS is a module-level mutable cache of promises that can persist across requests and leak request-specific state. Consider avoiding process-global request-specific caches.

Details

✨ AI Reasoning
​A module-level mutable object was introduced that stores promises for transaction status lookups keyed by txHash. Such a global persists across requests in long-running Node.js processes and can retain request-specific data or promises, causing unintended sharing or stale data across users/requests. This harms isolation between requests and can lead to data leakage or race conditions when different requests interact with the same txHash key.

🔧 How do I fix it?
Avoid storing request-specific data in module-level variables. Use request-scoped variables or explicitly mark shared caches as intentional.

_{Reply @AikidoSec feedback: [FEEDBACK] to get better review comments in the future.
Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info}

[effie-ms]

Removed the process-global cache for transaction status polling. Now each step execution gets its own cache object (transactionStatusObservers: {}) created in BaseStepExecutor.getBaseContext and passed through the execution context.

waitForTransactionStatus takes transactionStatusObservers to deduplicate polling for the same txHash within that step run. So deduplication is unchanged within a single step execution and there is no shared state across steps or requests, so there’s no cross-request leakage or wrong-step updates.