Add TP <> ContextExecutor integration + Jetton transfer error handling

[krebernisak]

ContextExecutor Integration for Token Pools

Summary

Replaces queryId-keyed pending maps with per-operation ContextExecutor contracts across all three token pool variants, enabling concurrent cross-chain operations without storage collision or circuit breaker limits.

What Changed

Architecture:

• Each async operation now deploys a deterministic ContextExecutor contract as a proxy to receive and forward completion messages (ReturnExcessesBack) with context
• Eliminates pendingBurns, pendingMints, pendingReleases, pendingLocks maps — no more queryId lookup or 65k cell storage limits
• Executor addresses are computed deterministically from (code, id, owner, context, forwardFrom) — no on-chain storage needed for routing

Token Pool Entrypoint entrypoint.tolk

• Added comprehensive error handling for onLockOrBurnTransfer with try/catch around forward payload decoding
• bestEffortReturnTransfer: Returns custody to sender on recoverable failures
• notifyLockOrBurnFailure: Sends failure notification with reserved pool balance protection
• reserveLockOrBurnFailureValue: Protects pool balance from being consumed by recovery messages

Pool Implementations (3 files):

• BurnMintTokenPool: Burn/mint flows use executors for async completion; full bounce handling with rate limit refund
• LockReleaseTokenPool: Release flow uses executor; RichBounce support for bounce recovery
• LockReleaseLockboxTokenPool: Both lock and release flows use executors; JettonLockBox_WithdrawFailed handling for withdrawal failures

JettonLockBox:

• Added failureContext field to JettonLockBox_WithdrawExtra, JettonLockBox_Deposited, and JettonLockBox_WithdrawFailed messages
• Propagates context through the withdrawal failure chain

ContextExecutor (minor):

• forwardFrom array now captured before clearing to prevent race conditions in message construction

[github-actions]

👋 krebernisak, thanks for creating this pull request!

To help reviewers, please consider creating future PRs as drafts first. This allows you to self-review and make any final changes before notifying the team.

Once you're ready, you can mark it as "Ready for review" to request feedback. Thanks!