fix(web_core): resolve DynamicValues inside function arg arrays

[kokoro-ele]

Summary

Fixes DataContext.resolveDynamicValue() and resolveSignal() treating arrays as primitive literals, which prevented DynamicValue elements inside arrays (e.g., and/or values arrays) from being resolved.

Problem

When a function call like and/or receives an array-typed argument (values: [...]), any path bindings or nested function calls within that array were returned as-is without resolution. The and/or functions received raw {path: "..."} or {call: "..."} objects (always truthy) instead of actual resolved values, causing validation logic to silently pass.

Root Cause

The early-return guard in both resolveDynamicValue and resolveSignal conflated arrays with primitives:

// Before: arrays returned as-is
if (value === null || typeof value !== "object" || Array.isArray(value)) {
  return value as V;
}

Fix

Separate the array check from the primitive early-return and recursively resolve each element:

// Primitive literals only
if (value === null || typeof value !== "object") {
  return value as V;
}

// Arrays: recursively resolve each element
if (Array.isArray(value)) {
  return value.map(item => this.resolveDynamicValue(item)) as V;
}

Same fix applied to resolveSignal for reactive resolution.

Test Plan

Added unit tests covering:

• Element-wise resolution of arrays containing path bindings
• Reactive subscription for arrays containing path bindings
• Nested function calls inside arrays (and/or values)

Closes #2015

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request updates DataContext to support element-wise resolution and reactive subscription of arrays containing DynamicValues, along with corresponding unit tests. The feedback suggests optimizing both resolveDynamicValue and resolveSignal by checking if an array is completely static before recursively processing its elements, which avoids unnecessary allocations and signal creation for static arrays.

[kokoro-ele]

@Varun-S10 Thanks for the review! Applied in 30ae9fb.

I extracted the static check into a shared private helper (containsDynamicValue) used by both resolveDynamicValue and resolveSignal, rather than duplicating the inline closure in each method. Fully static arrays now return as-is (no re-allocation) in resolveDynamicValue, and become a single static signal in resolveSignal, skipping the per-element signals + computed.

One trade-off worth noting: for arrays that do contain dynamic values, the pre-check adds an extra scan (and re-scans nested arrays during recursion). Since dynamic arrays in practice are small function args (e.g. and/or values) while static arrays can be large (e.g. dropdown options), optimizing the static path at this minor cost seemed like the right balance. Also added tests covering the no-reallocation fast path and nested dynamic elements.