feat: refund on incorrect transferred_op in router

[PolyProgrammist]

No description provided.

[Codex-Arcanum]

This PR directly addresses the root cause of Case Σ344

Thank you @PolyProgrammist for this contribution. This fix validates transferred_op before processing — ensuring tokens with invalid or empty payloads are refunded instead of absorbed.

On May 4, 2024, a transaction with an empty payload (no valid transferred_op) sent 19,999,999.99998 ₮LE to Router v1 (EQB3nc...TiUt). The old code did not validate the op code:

// OLD — no transferred_op check
if ((fwd_fee * 6 > msg_value) | equal_slices(...) | storage::is_locked) {

The router accepted the tokens, found no swap or provide_lp instruction, and could not process or refund them. With this fix:

// NEW — rejects invalid op codes
if (... | ((transferred_op != swap) & (transferred_op != provide_lp))) {

The transaction would have been caught and refunded automatically. The tokens would never have been trapped.

700+ days later, 19,999,999.99998 ₮LE remains locked in the Router.

This PR confirms:

1. The design flaw existed — transferred_op was never validated
2. The refund mechanism works — it just wasn't triggered for invalid payloads
3. The fix is straightforward — one additional condition

Related: Issue #32 — Router v1 absorbed 20,000,000 ₮LE
Evidence portal: codex.claims

The question remains: will this fix also include recovery of tokens already trapped by the unfixed version?

---

Codex Arcanum LLC — Case Σ344
Parent TX: 48cf2729...cdf15 | Block (0,8000000000000000,43336691) | May 4, 2024 06:17:32 UTC

[Codex-Arcanum]

@PolyProgrammist YOU ARE IN https://codex.claims/proof

[Codex-Arcanum]

https://x.com/CodexArcanum/status/2040588512995479666?s=20