Power the built-in panel down when the lid closes instead of leaving it lit

[dev-goalz]

Close the lid on a laptop and the built-in panel can stay backlit inside it. It goes
dark only when the idle timeout expires, ten minutes by default. On one machine here
the panel was still lit almost four minutes after the lid shut.

This happens when the internal panel is the only enabled output. should_handle_lid
requires two or more outputs, so with one the compositor releases its logind
inhibitor and ignores the lid entirely, and the lid switch handler is gated on
holding that inhibitor. logind policy then applies, and none of its options means
stay awake but blank. With HandleLidSwitch=lock the session locks and nothing ever
powers the panel down.

The >= 2 guard is right as far as it goes. Disabling the only output would leave
the session with nowhere to render. But powering a connector down is not the same as
disabling an output. The connector can go dark while the output stays configured and
present, which is what this does. When no inhibitor is held, the lid switch now sets
DPMS on the internal output instead of being ignored.

One more change is needed for that to hold. Every input event powers all surfaces
back on, including the lid switch itself, so internal outputs are exempted while the
lid is shut. That needs the lid state on hand, so it is tracked as a field on
Common and seeded from logind when outputs change, which also makes a compositor
started with the lid already closed behave correctly.

The second patch covers the case where the lid is shut and the external display goes
away, for instance when a dock is unplugged. Re-enabling the internal connector at
that point is not optional, since it is the only output left and a session with none
has nowhere to render, but it must not light up inside a closed lid. It is powered
down instead, the same trade the single-output path makes.

The lid state is a plain field rather than a logind query on purpose. Asking the bus
from the output configuration path deadlocked an earlier version of this change and
hung the greeter, so that call is not made there.

How it was checked

Running on one laptop since 2026-08-31 across daily dock and lid cycles, with no
recurrence of either the lit panel or the greeter hang that the first version caused.

This is only visible when HandleLidSwitch has been changed from the default
suspend, since suspending blanks the panel as a side effect. That limits who runs
into it, but a panel inside a closed lid arguably should not be lit whatever logind
is configured to do.

---

• I have disclosed use of any AI generated code in my commit messages.
• I understand these changes in full and will be able to respond to review comments.
• My change is accurately described in the commit message.
• My contribution is tested and working as described.
• I have read the Developer Certificate of Origin and certify my contribution under its conditions.

Written with assistance from Claude Opus 5.0, as disclosed in the commit message.
The changes were reviewed, built and run on a daily driver for five and a half
weeks before submitting, and I can answer review comments on any of it.

[leviport]

The PR template is required. Please add it back and complete the checklist.

[dev-goalz]

The PR template is required. Please add it back and complete the checklist.

Done