feat: Add Transaction Interceptor Support for Retry & Resilience Handling

## Problem

While looking through the transaction execution flow, I noticed that handling retries for temporary failures currently has to be done manually by the application.

In some cases, transactions can fail because a node is temporarily BUSY or due to short-lived network issues. Right now, there doesn’t seem to be a shared way to handle these scenarios centrally, so developers may end up writing similar retry logic in multiple places.

## Proposed Idea

It could be useful to introduce a TransactionInterceptor layer around the transaction.execute() phase, similar to a middleware/interceptor pattern.

This would make it easier to plug in reusable behaviors like:

- retry handling
- exponential backoff
- logging
- tracing/metrics

without changing transaction code throughout the application.

A possible direction could be:

- adding a TransactionInterceptor interface
- allowing ProtocolLayerClientImpl to execute transactions through an interceptor chain
- providing a default retry interceptor for transient failures such as BUSY

For example:
```
ExponentialBackoffRetryInterceptor
```
could automatically retry temporary failures with configurable retry limits and delays.

please assign this issue to me and i am open for discussion and feedback.

Start by tracing the transaction.execute() flow and reviewing ProtocolLayerClientImpl to understand where an interceptor chain could fit. Compare the existing transaction execution and failure handling with the proposed retry, backoff, logging, and tracing behaviors. Done means the interceptor contract, chain integration, and default transient-failure retry behavior are defined and covered by tests.

Written by the indexing model from the issue text.