fix(rpc): preserve nested bundle structure in mev_simBundle logs

[meetrick]

Summary

Fix log collection in mev_simBundle to preserve the hierarchical structure of nested bundles.

Problem

When MEV searchers simulate nested bundles using mev_simBundle, the response logs were flattened into a single array. This made it impossible to determine which transactions belonged to which nested bundle.

Example: Arbitrage strategy with backrun

Arbitrage Bundle
├── tx1: Buy on DEX A
├── Backrun Bundle
│   ├── tx2: Target transaction
│   └── tx3: Sell on DEX B
└── tx4: Collect profit

Before (Flattened - Structure Lost)

{
  "logs": [
    { "txLogs": ["tx1 logs"], "bundleLogs": null },
    { "txLogs": ["tx2 logs"], "bundleLogs": null },
    { "txLogs": ["tx3 logs"], "bundleLogs": null },
    { "txLogs": ["tx4 logs"], "bundleLogs": null }
  ]
}

→ Cannot identify tx2, tx3 belong to Backrun Bundle

After (Hierarchical - Structure Preserved)

{
  "logs": [
    { "txLogs": ["tx1 logs"], "bundleLogs": null },
    { "txLogs": null, "bundleLogs": [
        { "txLogs": ["tx2 logs"], "bundleLogs": null },
        { "txLogs": ["tx3 logs"], "bundleLogs": null }
    ]},
    { "txLogs": ["tx4 logs"], "bundleLogs": null }
  ]
}

→ Backrun Bundle clearly identified via bundleLogs

Note: txLogs and bundleLogs are mutually exclusive by design - a SimBundleLogs entry represents either a transaction (with txLogs) or a nested bundle (with bundleLogs), never both.

User Benefits

• Accurate debugging: Identify exactly which nested bundle caused failures
• Strategy analysis: Analyze gas usage and events per sub-bundle
• Proper API behavior: SimBundleLogs.bundle_logs field now works as intended

Changes

• Add build_bundle_logs() using stack-based iteration to reconstruct log hierarchy (avoids recursive calls)
• Add bundle_path field to FlattenedBundleItem to track each transaction's position in the bundle hierarchy
• Store logs in HashMap during execution for structure reconstruction
• Add 4 unit tests for nested bundle log collection

[mattsse]

{ "txLogs": null, "bundleLogs": [
{ "txLogs": ["tx2 logs"], "bundleLogs": null },
{ "txLogs": ["tx3 logs"], "bundleLogs": null }
]},

does that mean that txLogs and bundeLogs are mutually exclusive?

[mattsse]

thanks, all of this makes sense

but I believe we can also populate the logs if use smth like a stack of logs instead because I'd like to avoid having recursive calls here

[meetrick]

maybe a better approach here would be to include the bundle depth in the FlattenedBundleItem as an identifier then we can populate the body_logs properly

Yes, txLogs and bundleLogs are mutually exclusive by design.
And I'll refactor to remove the recursive call.

[meetrick]

@mattsse I have updated the code based on your suggestion and ran the tests using the same approach as before.
I would appreciate it if you could take another look.