VDA5050 2.0: cancelOrder is resent even after vehicle reports it RUNNING

[yaeby]

Defect

Affected version

opentcs-commadapter-vda5050 Release 0.33.0

Scope

VDA5050 2.0 only

Steps to reproduce

1. Vehicle is mid-order execution
2. In OperationsDesk, trigger Withdraw transport order and stop vehicle immediately.
3. Vehicle published where actionStates with:
   • actionId as sent by openTCS
   • actionType: cancelOrder
   • actionStatus: RUNNING
4. OpenTCS sends cancelOrder again (same actionId), because actionStatus: RUNNING.
5. AGV immediately reports in errors[] duplicate instant action with same actionId.
6. That error state message triggers openTCS to send cancelOrder again.
7. AGV again reports duplicate-action error.
8. Loop happens until AGV eventually reports the cancelOrder as FINISHED or FAILED.

Expected behaviour

When a cancelOrder action is present in actionStates with the same
actionId (including RUNNING), openTCS should treat it
as acknowledged/accepted and must not resend it.

However, openTCS should still keep subsequent queued
orders/messages blocked until that cancelOrder reaches a terminal
state (FINISHED or FAILED).

In short:

• RUNNING => acknowledged (no resend)
• only FINISHED/FAILED => unblock next queued request

Actual behaviour

A resend loop occurs while cancelOrder is RUNNING:

• openTCS sends cancelOrder
• AGV reports cancelOrder: RUNNING
• openTCS resends same cancelOrder (same actionId)
• AGV reports duplicate instant action error
• that state causes openTCS to resend again

This creates unnecessary traffic and repeated AGV errors until
terminal action status is reported.

Acceptance criteria

• Actual behavior corrected:
• New tests added or existing tests improved to prevent regressions
• Changelog entry added

/label ~defect

[swltr]

Fix merged with openTCS/opentcs-commadapter-vda5050#19.