[BUG] `len` function passes garbage value when evaluated as an argument.

**Describe the bug**
When using the `len` function to take the length of an array as an argument to a function call, it passes an incorrect value in a format such as _\_length\_1[@]. This behavior is not seen when assigning the result of `len` to a variable and then passing that variable to the function.

**To Reproduce**
```js
import { printf } from "std/env"

fun print_length(length: Int) {
echo(length)
}

// this prints the incorrect __length_1[@] text
let arr = ["a", "b"]
printf("Calling len function: ")
print_length(len(arr))

// this prints correctly
let arr_len = len(arr)
printf("Assigning len to a variable: ")
print_length(arr_len)

fun length_plus_one(length: Int): Int {
// bash error: bad array subscript
return length + 1
}

printf("Integer operation: ")
length_plus_one(len(arr))
```

This creates the output (on bash-4.3):

```
Calling len function: __length_2[@]
Assigning len to a variable: 2
Integer operation: bash: line 46: __length_6[@]: bad array subscript
```

This reproduces when compiling to all available targets (bash-4.3, bash-3.2, zsh, ksh). It's notable that while the value generated by `len` as a parameter is not a valid `Int`, it still type checks as a regular `Int`, which I verified with an `if length is Int` check. This behavior is also not seen from other function calls, including a wrapper function immediately returning `len` of a value.

**Expected behavior**
A `len` call passed as a parameter should be evaluated to a plain `Int` with a value which is only a single number and no extra labels or strings, and which can be used for int operations.

**Additional context**
Environment:
- MacOS Sequoia 15.6
- amber 0.6.0-alpha