fix: support variable parsing in arrays for job arguments

[androidfans]

Previously, variables like $var:f/path/to/variable were not being
resolved when they appeared inside arrays in job arguments. This was
because the transform_json_value function in common.rs only
handled recursive transformation for Value::Object, but was missing
the case for Value::Array.

This commit adds support for recursively transforming array elements,
allowing variables to be properly resolved when used within arrays.

Example:

• Before: ["$var:f/Narration/jina_api_key"] would remain as literal string
• After: ["jina_this_is_real_jian_key_value"] (variable is properly resolved)

Note: String concatenation with variables (e.g., "Bearer: $var:...")
is still not supported as it requires a more complex implementation
with regex-based pattern matching and substitution.

Fixes issue #7253 where variables in array parameters were not being parsed.

[github-actions]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

rejectliu seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}

[androidfans]

This issue found when i am trying to migrate my script from N8N, to align function with n8n

[rubenfiszel]

Issue is that it will add a lot of compute to any jobs with very long/big arrays which I'm not a fan of. It's possible to do this with a bit more guards around length and depth of this recursivity (n<= 100, depth <= 3) but then it becomes harder to predict.

[androidfans]

Issue is that it will add a lot of compute to any jobs with very long/big arrays which I'm not a fan of. It's possible to do this with a bit more guards around length and depth of this recursivity (n<= 100, depth <= 3) but then it becomes harder to predict.

I don't think users would add over 100 items through the web interface. If they did, the web page would probably crash before they managed to add that many anyway. 😂