Support interval+reduce in the area mark

[Fil]

Defaults y to the reducer when creating a dense interval.

There is a discrepancy between line and area, where the default y = identity is set:

export function lineY(data, {x = indexOf, y = identity, ...options} = {}) {
  return new Line(data, maybeDenseIntervalX({...options, x, y}));
}

export function areaY(data, options) {
  const {x = indexOf, ...rest} = maybeDenseIntervalX(options);
  return new Area(data, maybeStackY(maybeIdentityY({...rest, x1: x, x2: undefined}, x === indexOf ? "y2" : "y")));
}

in line, it is set immediately, whereas in area it is set in maybeIdentityY, which comes after the determination of the dense interval in maybeDenseIntervalX. By way of consequence, the dense interval does not apply the reducer to any channel.

With this change, the default reducer is applied to y when it's undefined.

An unwelcome consequence is that this defines y even when y1/y2 are defined? But I don't think it has an impact in practice, because when y2 is used y is ignored.

closes #2328

---

For fun I tried to solve this with Claude Code.

I've left the agent's solution as the first commit (including unit tests); I did not touch the files at all for that first commit, so I signed it with Claude's email. (The commit message is also Claude's, although I added the costs below, because the agent told me it didn't have access to this information.)

In the second commit I reversed Claude's approach, and applied a human solution instead. Is it better or worse? I'll ask copilot for an opinion.

[mbostock]

More description about how this fixes the problem would be helpful in the PR. (And it would be more relevant than your experience with AI, though I appreciate you sharing!) I guess this changes the behavior exactly when y is undefined, but preserves the current behavior when y is null. Will anything else be affected by this fix?

[Fil]

Good call. I added details in the description.