runtime error: makeslice: cap out of range

Steps to reproduce:
List the minimal actions needed to reproduce the behavior.

Running filter function to filter empty table leads to a panic:
```
import "internal/promql"

table1_l = from(bucket: "tsdb")
|> range(start: 2022-09-04T16:00:00Z, stop: 2022-09-04T18:00:00Z)
|> filter(fn: (r) => r._measurement == "A" and r._field == "count")
|> group(columns: ["channel"], mode: "by")
|> aggregateWindow(period: 30m, every: 30m, fn: sum, column: "_value", timeSrc: "_start", createEmpty: false)
|> drop(columns: ["_measurement", "_field", "_start", "_stop"])

table1_r = from(bucket: "tsdb")
|> range(start: 2022-09-04T16:00:00Z, stop: 2022-09-04T18:00:00Z)
|> filter(fn: (r) => r._measurement == "B" and r._field == "count")
|> group(columns: ["channel"], mode: "by")
|> aggregateWindow(period: 30m, every: 30m, fn: sum, column: "_value", timeSrc: "_start", createEmpty: false)
|> drop(columns: ["_measurement", "_field", "_start", "_stop"])

promql.join(left: table1_l, right: table1_r, fn: (left, right) => ({left with _value: float(v: left._value / right._value)}))
|> filter(fn: (r) => exists r._time, onEmpty: "drop")
```
The idea is to filter empty table just avoid affecting other calculations (the promql.join may be generate empty table)

Expected behavior:
The query runs successfully

Actual behavior:
Query error with a runtime panic

panic error:
panic: runtime error: makeslice: cap out of range" stacktrace="goroutine 26708619898 [running]:
runtime/debug.Stack()
/go/src/runtime/debug/stack.go:24 +0x65
github.com/influxdata/flux/execute.(*poolDispatcher).recover(0xce3ee96930)
/go/pkg/mod/github.com/influxdata/flux@v0.171.0/execute/recover.go:53 +0x205
panic({0x3025740, 0x3397b58})
/go/src/runtime/panic.go:838 +0x207
github.com/influxdata/flux/stdlib/universe.(*filterTransformation).Process(0xce13e1e0e0, {{{0x33cc520, 0xc78845e410}, {0x0, 0x0, 0x0}, {0x885e4b8, 0x0, 0x0}}}, 0xd190e92440, ...)
/go/pkg/mod/github.com/influxdata/flux@v0.171.0/stdlib/universe/filter.go:171 +0x1da
github.com/influxdata/flux/execute.(*narrowTransformation).ProcessMessage(0xcff1072798, {0x33b6468?, 0xc8f0c4af00})
/go/pkg/mod/github.com/influxdata/flux@v0.171.0/execute/narrow_transformation.go:43 +0x371
github.com/influxdata/flux/execute.(*transportTransformationAdapter).processChunk(...)
/go/pkg/mod/github.com/influxdata/flux@v0.171.0/execute/transport.go:757
github.com/influxdata/flux/execute.(*transportTransformationAdapter).Process(0xd3559dffd0, {0x79, 0x99, 0x8c, 0x45, 0x76, 0x74, 0x57, 0xc, 0xb9, ...}, ...)
/go/pkg/mod/github.com/influxdata/flux@v0.171.0/execute/transport.go:737 +0x318
github.com/influxdata/flux/execute.(*transportTransformationAdapter).ProcessMessage(0xd3559dffd0, {0x33b64a0?, 0xd0347074e0})
/go/pkg/mod/github.com/influxdata/flux@v0.171.0/execute/transport.go:722 +0x13e
github.com/influxdata/flux/execute.(*consecutiveTransport).processMessage(0xc77a688870, {0x33b64a0, 0xd0347074e0})
/go/pkg/mod/github.com/influxdata/flux@v0.171.0/execute/transport.go:292 +0xca
github.com/influxdata/flux/execute.(*consecutiveTransport).processMessages(0xc77a688870, {0x33b56d8?, 0xd39a9f1a80?}, 0xa)
/go/pkg/mod/github.com/influxdata/flux@v0.171.0/execute/transport.go:246 +0xe5
github.com/influxdata/flux/execute.(*poolDispatcher).doWork(0xce3ee96930, {0x33b56d8, 0xd39a9f1a80})
/go/pkg/mod/github.com/influxdata/flux@v0.171.0/execute/dispatcher.go:157 +0x19f
github.com/influxdata/flux/execute.(*poolDispatcher).run(0xce3ee96930, {0x33b56d8, 0xd39a9f1a80})
/go/pkg/mod/github.com/influxdata/flux@v0.171.0/execute/dispatcher.go:135 +0x4f
github.com/influxdata/flux/execute.(*poolDispatcher).Start.func1()
/go/pkg/mod/github.com/influxdata/flux@v0.171.0/execute/dispatcher.go:75 +0x86
created by github.com/influxdata/flux/execute.(*poolDispatcher).Start
/go/pkg/mod/github.com/influxdata/flux@v0.171.0/execute/dispatcher.go:71 +0x48

Environment info:

InfluxDB version: 2.3, flux version: 0.171.0

Start by reproducing the query against InfluxDB 2.3 with Flux 0.171.0, then inspect filter.go at line 171 in the stack trace and the surrounding filter transformation logic. Done means the provided query returns successfully when the joined input produces an empty table, without a runtime panic.

Written by the indexing model from the issue text.