feat(vm): check CREATE2 max depth under Osaka

[yanghang8612]

What does this PR do?

Extends the CREATE2 (Program.createContract2) maximum call-depth guard so it also takes effect under the Osaka fork. The guard pushes 0 and returns when the call depth reaches MAX_DEPTH (64); it was previously gated only on allowTvmCompatibleEvm() and is now gated on allowTvmCompatibleEvm() || allowTvmOsaka().

Why are these changes required?

The ALLOW_TVM_OSAKA proposal only gates on the VERSION_4_8_2 fork and does not require ALLOW_TVM_COMPATIBLE_EVM as a prerequisite (see ProposalUtil). Osaka can therefore be active while allowTvmCompatibleEvm is still off, in which case a max-depth CREATE2 would fail to short-circuit as expected. Gating the guard on Osaka as well keeps CREATE2's max-depth behavior consistent whenever Osaka is enabled. (CREATE, CALL and the other call paths already enforce this depth check unconditionally.)

This PR has been tested by:

• Unit Tests
• Manual Testing

Added OperationsTest#testCreate2MaxDepthWithOsakaOnly: enables Osaka only (allowTvmCompatibleEvm = 0, allowTvmOsaka = 1), invokes createContract2 at depth 64, and asserts that 0 is pushed onto the stack and no internal transaction is created.

Follow up

None.

Extra details

Single-line behavioral change; paths where allowTvmCompatibleEvm is enabled are unaffected.

[CodeNinjaEvan]

Would be great to add a test case where both allowTvmCompatibleEvm and allowTvmOsaka are false, just to explicitly confirm that CREATE2 behaves as expected when neither flag is enabled. Helps make the intent clear for future readers!

[yanghang8612]

Good idea, thanks! Added testCreate2MaxDepthWithNeitherFlag in the latest push: with both allowTvmCompatibleEvm and allowTvmOsaka disabled, the MAX_DEPTH short-circuit is not taken, so at max depth CREATE2 still proceeds as before — it records an internal transaction and pushes the new contract address instead of 0. This documents the baseline behavior alongside the Osaka-only case for future readers. PTAL.