panic: deep binary expression in SELECT projection aborts with stack overflow

### Describe the bug

A deeply chained arithmetic expression in a `SELECT` projection (e.g. `1+1+1+...+1` with ~2000 `+` operators) aborts the process with a stack overflow rather than returning an error.

Related to but distinct from #8900 (deep `WHERE`) and #16030 (substrait → binary operators). This reproduces from a plain SQL `SELECT`, with no filter, join, or substrait involved — just a deeply nested binary expression in a projection. The recursion site is presumably one of the SQL-expression or logical-plan walks.

### To Reproduce

```bash
cargo run -p datafusion-cli -- -c "SELECT $(printf '1+%.0s' {1..2000})1"
```

(i.e. `SELECT 1+1+1+...+1` with ~2000 `+` operators.)

Around 1000 operators completes normally; somewhere between 1000 and 2000 it crosses the stack limit on a default 8 MiB main-thread stack.

### Actual behavior

```
DataFusion CLI v53.1.0

thread 'main' has overflowed its stack
fatal runtime error: stack overflow, aborting
```

Process exits with signal `SIGABRT` (exit code 134).

### Expected behavior

Either complete the query, or return a clean planning error like `"expression nesting depth exceeds recursion limit"` (analogous to PostgreSQL's `max_stack_depth` error). A user-supplied SQL string should not be able to abort the process.

### Environment

- DataFusion CLI v53.1.0 (from `main` at commit 8741a7752c)
- macOS, default main-thread stack size

### Additional context

Found by running hand-crafted SQL through `cargo run -p datafusion-cli -- -c ...`. Tracks under the broader umbrella of #16788 ("Restructure core codepaths to prevent stack overflows") — filing a concrete, reproducer-backed example so the projection-expression path is tracked alongside the filter/substrait ones already on file.