Specialize macro list folds

[snazy]

Recognize map and filter macro fold shapes during planning and build result lists with a mutable evaluation-local buffer.

This avoids repeated accumulator list copying while preserving generic fold fallback for non-standard accumulator references.

[XN137]

should this try to use Sizer first or instead (as we do in listCapacity) ?

[snazy]

Nice catch! I already have a follow-up for that.

[XN137]

minor sonnet finding:

  EvalExhaustiveListFold.eval() handles errors inconsistently depending on their source.

  Filter errors overwrite result unconditionally:
  if (include != True) {
      result = noSuchOverload(null, Operator.Conditional.id, include);  // always overwrites
      continue;
  }

  Transform errors only set result if it's still null:
  if (result == null) {
      if (isUnknownOrError(value)) {
          result = value;  // only captures the first
      }
  }

  The consequence: if a transform error occurs on element 1, then a filter error occurs on element 2, the transform error is silently replaced by the filter error. Conversely, multiple transform errors always return the first one, while
  multiple filter errors return the last one. There's also no test covering the filter-returns-error path in exhaustive mode at all (both existing exhaustive tests use include == False or a transform that errors, not a filter that returns
  a non-boolean).

  The fix would be to guard the filter-error assignment with the same result == null check:
  if (include != True) {
      if (result == null) {
          result = noSuchOverload(null, Operator.Conditional.id, include);
      }
      continue;
  }

  This is a low-severity issue since exhaustive mode is primarily for cost estimation and observability rather than production evaluation paths, and erroring filter conditions are rare. But the inconsistency is real and would be easy to
  fix.

[snazy]

Good catch! I'll keep it in mind!