test: multi-handler ordering regression in ExternalActionPlugin

[shahabdsh]

Summary

Adds tests demonstrating a behavioral regression introduced in #832 (refactor of ExternalActionPlugin from transition + setTimeout to afterTransition).

The issue

When multiple ExternalActionPlugin instances are registered on the same Player (common in plugin architectures where a host and embedded component each register their own handler):

• Before Refactor external action plugin #832: If the first handler resolved synchronously, the second handler was never invoked — the player had already transitioned away from the external state by the time the second handler's setTimeout callback ran.
• After Refactor external action plugin #832: Both handlers are always invoked regardless, because afterTransition fires both synchronously in the same tick, and both capture currentState before either has transitioned.

This means handlers that have side effects (logging, analytics, network calls, state mutations) now execute even when another handler has already resolved the external state — which can cause unexpected behavior in plugin architectures.

Test cases

Test	Expected	Actual (main)
First handler sync, second should not be called	PASS	FAIL — second handler is called
First handler async fast, second async slow	PASS	PASS
First handler returns undefined, second handles	PASS	PASS

Suggested fix

The afterTransition approach should check whether the external state has already been resolved before invoking the handler, or use a coordination mechanism (e.g., a flag on the flow instance) to prevent multiple handlers from racing.

🤖 Generated with Claude Code