FunC ignores arg/ret order metadata when calling built-ins or asm functions via variables

[Gusarich]

The FunC compiler incorrectly handles built-in functions (e.g., moddiv) and asm functions with custom argument or return order annotations when they are invoked through variables. Specifically, it ignores the arg_order and ret_order metadata, leading to incorrectly ordered return values at runtime.

Minimal example (built-in and asm, direct vs indirect calls):

;; Correct: directly calls built-in, respects ret_order
(int, int) correctBuiltin(int a, int b) {
    return moddiv(a, b);
}

;; Incorrect: calling built-in via variable, ignores ret_order
(int, int) incorrectBuiltin(int a, int b) {
    var f = moddiv;
    return f(a, b);
}

;; Define the asm function with explicit ret_order
(int, int) myAsm(int a, int b) asm(-> 1 0) "SWAP";

;; Correct: directly calls asm function with explicit ret_order
(int, int) correctAsm(int a, int b) {
    return myAsm(a, b);
}

;; Incorrect: calls asm function via variable, ignores ret_order
(int, int) incorrectAsm(int a, int b) {
    var f = myAsm;
    return f(a, b);
}

() main () {
    ~dump([correctBuiltin(5, 1)]);    ;; [0 5] ✅
    ~dump([incorrectBuiltin(5, 1)]);  ;; [5 0] ❌
    ~dump([correctAsm(5, 1)]);        ;; [5 1] ✅
    ~dump([incorrectAsm(5, 1)]);      ;; [1 5] ❌
}

Expected Output:

[0 5]
[0 5]
[1 5]
[1 5]

Actual Output:

[0 5]
[5 0]
[5 1]
[1 5]

Cause:
When compiling function calls via variables, FunC currently ignores arg_order and ret_order metadata, causing incorrect assembly instructions and resulting in misordered runtime values.

Impact:
Contracts relying on indirect function calls to built-ins or annotated asm functions will silently produce incorrect results, potentially causing severe runtime logic errors.

Expected Behavior:
The compiler must correctly handle and apply arg_order and ret_order metadata, whether functions are called directly or indirectly.

---

LLM Fuzzing discovery (see tact-lang/tact#3123)