Incorrect integral calculations for short activities

I have a value series consisting of 1s and 0s, representing the on/off state of a device. I'd like to calculate the integral of this series for a specified time range, but it gives me incorrect results, no matter if I use the integral() function by itself or within aggregateWindow().
I'll give one nice example but I can reproduce it with almost all kinds of similar value series.

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

1. The input data from my base query looks like this:
   (There is a standard sampling every minute, reflecting the current state, but if the state changes in between, additional values are added.)

2. I use either one of the following integral code blocks (no interpolation):

|> aggregateWindow(
    every: duration(v: uint(v: v.timeRangeStop) - uint(v: v.timeRangeStart)),
    fn: (tables=<-, column) =>
    tables
        |> sort(columns: ["_time"])
        |> integral(unit: 1s)
    ,
    createEmpty: false
)

|> integral(unit: 1s)

Expected behaviour:
If you calculate the integral by just looking at the table, it's 46 seconds (25+14+7).

Actual behaviour:
When using either of the integral codes, I get the same wrong result, 86.96 seconds:

Environment info:

InfluxDB running in Docker:

Config:
Default

Start by reproducing the integral() and aggregateWindow() queries from the issue against the supplied 0/1 time series on InfluxDB 2.7.11. Compare the reported 86.96-second result with the expected 46 seconds; the issue does not name implementation files or tests, so locating the relevant integral code and regression coverage will require repository research.