revert: restore createPod/stake forwarding to the EigenPodManager (undo #493)

[0xpanicError]

Revert of #493

The protocol still needs the ability to create new EigenPods and stake into them via the forwarding path (EtherFiNode.forwardExternalCall → EigenPodManager.createPod/stake). #493 blocked exactly that, so this restores the unrestricted forwardExternalCall and removes the deny test.

What changes

• EtherFiNode.forwardExternalCall back to return LibCall.callContract(to, 0, data); (no selector/target restriction).
• Deletes test/behaviour-tests/forwarding-createpod-deny.t.sol.

Trade-off (accepted, worth an auditor/ops note)

This reopens re-review MED 2: a node's pod-or-no-pod status is no longer immutable in code. Because the credential resolver derives node→pod from getEigenPod(), attaching a pod to a node that already has pod-less validators would flip that node's credential resolution from node to pod (breaking EL-triggered exits for those validators). The invariant is now enforced operationally via the per-caller forwarding whitelist (only the operating timelock can grant createPod/stake entries) rather than in the contract — so the guardrail is: never whitelist pod creation for a node that already runs pod-less validators.

Tests: forwarding-whitelist suite 2 green, credentials 79 green.

Base: pankaj/feat/non-eigenpod-withdrawal-credentials.

🤖 Generated with Claude Code

---

Note

Medium Risk
Reopens a credential-resolution invariant that was previously hard-blocked on-chain; safety now depends on forwarding whitelist discipline rather than contract-level denial.

Overview
Reverts #493 so the protocol can again create EigenPods and stake through the manager → node forwarding path (EtherFiNodesManager.forwardExternalCall → EtherFiNode.forwardExternalCall → EigenPodManager).

EtherFiNode.forwardExternalCall no longer inspects to == eigenPodManager or rejects createPod / stake selectors; it only forwards via LibCall.callContract. The behaviour test forwarding-createpod-deny.t.sol is removed.

Trade-off: pod-vs-pod-less status is no longer enforced in the node contract. Whitelisted forwarding could attach a pod to a node that already runs pod-less validators and change credential resolution (node → pod). That risk is shifted to ops: only grant createPod/stake on the forwarding whitelist when safe (operating timelock on updateAllowedForwardedExternalCalls).

^{Reviewed by Cursor Bugbot for commit 12de167. Bugbot is set up for automated code reviews on this repo. Configure here.}

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Credits must be used to enable repository wide code reviews.