[Advanced]: Support Pectra EVM Type 4 Transaction Encoding (EIP-7702)

## 🧠 Advanced

This issue is well-suited for contributors who are very familiar with the Hiero C++ SDK and enjoy working with its core abstractions and design patterns.

Advanced Issues often involve:
- Exploring and shaping SDK architecture
- Reasoning about trade-offs and long-term impact
- Working across multiple modules or systems
- Updating tests, examples, and documentation alongside code

The goal is to support thoughtful, high-impact contributions in a clear and collaborative way.

---

## 🐞 Problem Description

As part of the upcoming **Pectra upgrade** to Hiero networks, [EIP-7702: Set Code for EOAs](https://eips.ethereum.org/EIPS/eip-7702) introduces **Type 4 transactions** (also known as `SET_CODE_TX_TYPE`). This new transaction type allows Externally Owned Accounts (EOAs) to delegate code execution to smart contracts, enabling features like:

- Transaction batching
- Sponsored/gasless transactions
- Session keys and permissioned sub-keys
- Smart wallet capabilities while preserving EOA identity

The Hiero C++ SDK currently does not support encoding or decoding Type 4 transactions. To prepare for the Pectra upgrade, the SDK must be able to construct and send these transactions to consensus nodes.

### Technical Background

Type 4 transactions introduce a new RLP-encoded structure with an **authorization list**:

```
rlp([
chain_id,
nonce,
max_priority_fee_per_gas,
max_fee_per_gas,
gas_limit,
destination,
value,
data,
access_list,
authorization_list, // NEW: list of authorization tuples
signature_y_parity,
signature_r,
signature_s
])
```

Each entry in `authorization_list` is a tuple:
```
[ chain_id, address, nonce, y_parity, r, s ]
```

Where the authority (EOA) signs over `keccak(MAGIC || rlp([chain_id, address, nonce]))` with `MAGIC = 0x05`.

### Key Parameters

| Parameter | Value |
|-----------|-------|
| `SET_CODE_TX_TYPE` | `0x04` |
| `MAGIC` | `0x05` |
| `PER_AUTH_BASE_COST` | 12,500 gas |
| `PER_EMPTY_ACCOUNT_COST` | 25,000 gas |

---

## 💡 Proposed / Expected Outcome

Implement full SDK support for EIP-7702 Type 4 transactions, including:

1. **New data structures** for authorization tuples and authorization lists
2. **RLP encoding/decoding** for Type 4 transaction format
3. **Signature handling** for authorization tuple signing (MAGIC prefix, proper hashing)
4. **Integration** with existing `EthereumTransaction` infrastructure
5. **Validation** of chain IDs, nonces, and signature parameters
6. **Public API** that allows users to construct and sign Type 4 transactions

The implementation should:
- Follow patterns established in other Hiero SDKs for consistency
- Preserve backwards compatibility with existing transaction types
- Provide clear, actionable error messages for invalid inputs
- Be well-documented with usage examples

---

## 🧠 Implementation & Design Notes

### Suggested Approach

1. **Review the design document**:
https://github.com/hiero-ledger/sdk-collaboration-hub/pull/118

2. **Study EIP-7702 specification**:
https://eips.ethereum.org/EIPS/eip-7702

3. **Identify affected areas** in the C++ SDK:
- `src/sdk/main/src/` - Transaction classes and encoding
- `src/sdk/main/include/` - Public API headers
- Existing `EthereumTransaction` implementation for patterns

4. **Design new classes/structures**:
- `AuthorizationTuple` or similar for individual authorizations
- Extension to `EthereumTransaction` or new transaction class for Type 4

5. **Implement RLP encoding**:
- Handle the new authorization_list field
- Ensure proper serialization order and types

6. **Implement signature logic**:
- MAGIC prefix (`0x05`) for authorization signing
- Proper keccak hashing of authorization data
- Signature validation (s <= secp256k1n/2 per EIP-2)

7. **Add comprehensive tests**:
- Unit tests for encoding/decoding
- Integration tests for transaction submission
- Edge cases (empty authorization list, multiple authorizations, etc.)

8. **Provide usage example(s)**:
- Demonstrate constructing a Type 4 transaction
- Show how to create and sign authorization tuples

### Key Considerations

- **Chain ID validation**: Authorization tuples can have chain_id = 0 (valid on all chains) or must match the current chain
- **Nonce handling**: Each authorization increments the authority's nonce
- **Delegation indicator**: The code set on delegation is `0xef0100 || address`
- **Gas calculations**: Include `PER_EMPTY_ACCOUNT_COST * authorization_list.length` in intrinsic gas

---

## ✅ Acceptance Criteria

A pull request for this issue should:

- [ ] Implement Type 4 transaction encoding per EIP-7702 specification
- [ ] Implement authorization tuple/list data structures
- [ ] Implement proper signature handling for authorizations (MAGIC prefix)
- [ ] Integrate with existing `EthereumTransaction` infrastructure
- [ ] Maintain backwards compatibility with existing transaction types
- [ ] Follow existing architectural and C++ conventions in the SDK
- [ ] Include comprehensive unit and integration tests
- [ ] Provide at least one usage example
- [ ] Update relevant documentation
- [ ] Pass all CI checks

---

## 📚 Additional Context, Links, or Prior Art

### Design Document
- **SDK Collaboration Hub PR # 118**: https://github.com/hiero-ledger/sdk-collaboration-hub/pull/118

### Specifications
- **EIP-7702 (Set Code for EOAs)**: https://eips.ethereum.org/EIPS/eip-7702
- **EIP-2718 (Typed Transaction Envelope)**: https://eips.ethereum.org/EIPS/eip-2718

### Related Resources
- **Pectra Upgrade Info**: https://pectra.org/
- **EIP-7702 Security Considerations**: Authorization signatures can be phished; the SDK should provide clear warnings/documentation about risks

### Cross-SDK Alignment
This implementation should align with patterns used in other Hiero SDKs. Check the design document for cross-SDK consistency requirements.