fix: make WasmBase::doAfterVmCallActions reentry-safe (drain-to-local)

[johnlanni]

Problem

WasmBase::doAfterVmCallActions() drained its after_vm_call_actions_ queue with an
unguarded while (!after_vm_call_actions_.empty()) loop, popping and running one action
at a time. If an action re-enqueues itself (or otherwise adds a new action) during the
drain, the freshly-added action is observed by the same loop and executed again in the
same frame. Under synchronous reentry — e.g. a plugin that calls
injectEncodedDataToFilterChain from within an after-VM-call action, which schedules
another after-VM-call action — the loop never sees an empty queue and spins forever,
pinning a CPU at 100%.

Fix

Swap the member queue into a local std::deque before draining, then iterate the local
snapshot exactly once. Actions re-added by a callback during the drain land in the
(now-empty) member queue and are therefore picked up by the next-outer
DeferAfterCallActions frame instead of being re-run in this loop. This breaks the
synchronous-reentry spin while preserving ordering semantics for legitimately deferred work.

This is a header-only change to a small inline method:

• Zero-ABI / transparent to plugins — no signature or behavior change visible to WASM modules.
• Re-added actions are still executed; they are just deferred to the next-outer frame.

Test

Adds TEST_P(TestVm, DoAfterVmCallActionsReentrySafe) in test/wasm_test.cc, wired into the
existing //test:wasm_test target. It registers a self-re-enqueuing action and asserts the
count advances by exactly one per doAfterVmCallActions() call. On the old code this test
would hang forever (documenting the regression); with the fix each drain runs the snapshot
once and defers the re-added copy.

Notes

• CI is the build/test gate.
• Merge is intentionally gated on maintainer review — please do not self-merge.

Refs

• Fixes context: Wasm 插件死循环：onRedisCallFailure + injectEncodedDataToFilterChain 嵌套导致 Envoy CPU 100% 跑满 higress#4034
• Design: Design: drain-to-local in WasmBase::doAfterVmCallActions (Layer A, #4034) higress#4070 (Layer A)
• Spec: SPEC-001