"Light brightness" condition and "Light brightness crossed threshold" trigger do not behave as expected for multiple lights

### The problem

The documentation for the recently added "[Light brightness](https://www.home-assistant.io/conditions/light.is_brightness/#:~:text=A%20light%20that%20is%20off%20has%20brightness%20zero%2C%20so%20it%20never%20meets%20a%20positive%20threshold.)" condition states:

> A light that is off has brightness zero, so it never meets a positive threshold.

Similarly, but perhaps less directly for this issue, the "[Light brightness crossed threshold](https://www.home-assistant.io/triggers/light.brightness_crossed_threshold/#:~:text=A%20light%20at%200%25%20(off)%20and%20the%20same%20light%20at%201%25%20are%20both%20below%20a%2050%25%20threshold.)" trigger documentation states:

> A light at 0% (off) and the same light at 1% are both below a 50% threshold.

When using `behavior: all` and `threshold: type: below`, the condition always appears to be false and the trigger never fires as long as at least one of the specified lights is `off`.

The reason seems obvious to me, that for any lights that are `off`, their `brightness `is `null`. The trace seems to confirm this with a message at the top:

> This trigger evaluated a relevant change but did not trigger the automation. The reason is shown in the result below.

```
reason: entity_value_not_numeric
data:
entity_id: light.kitchen_light_strip
value: null
```

Still, that's in conflict with how I read the documentation. To me, the "Light brightness" condition quote above implies that when evaluating the condition, it treats any light that is `off ` as having a `brightness` of `0`, rather than the `null` value that the actual attribute has. The "Light brightness crosses threshold" trigger doesn't make quite the same equivalency (saying a light that is at 0% is off, but not asserting the opposite is true), but I don't think considering a light that turned off to have crossed a positive threshold is illogical.

There are simple enough ways to work around this, but they're definitely less convenient than these new conditions and triggers where I can just target a whole room at once rather than creating a group or building more complex logic.

Is the current behavior as intended or a bug?

### What version of Home Assistant Core has the issue?

core-2026.9.1

### What was the last working version of Home Assistant Core?

_No response_

### What type of installation are you running?

Home Assistant OS

### Integration causing the issue

Light

### Link to integration documentation on our website

https://www.home-assistant.io/conditions/light.is_brightness/

### Diagnostics information

_No response_

### Example YAML snippet

```yaml
trigger: light.brightness_crossed_threshold
target:
area_id: kitchen
options:
behavior: all
threshold:
type: below
value:
active_choice: number
number: 20

condition: light.is_brightness
target:
area_id: kitchen
options:
threshold:
type: below
value:
active_choice: number
number: 20
behavior: all
```

### Anything in the logs that might be useful for us?

_No response_

### Additional information

_No response_

Start with the Light brightness condition and Light brightness crossed threshold trigger referenced in the issue, using the supplied YAML with multiple lights and behavior: all as the reproduction. Compare the documented handling of an off light with the observed null value and entity_value_not_numeric trace. Done means the intended behavior is confirmed or corrected consistently for both cases, with regression coverage for multiple lights.

Written by the indexing model from the issue text.