fix(display): a clamshell undock latched, so the NEXT undock never ran

Bernardo, live, right after #127 TEST A: undocked → the panel stayed dark;
re-docked and undocked again → it came back. Re-docking is not what fixed
it. OPENING THE LID was.

awaiting_lid_open is set by every successful undock and cleared only when
the external is gone AND the lid is open — so a clamshell undock latches
it. Re-docking clears its sibling undock_pending ("a new external
supersedes any undock still queued for an older departure") but not this
one, and the clear cannot fire while an external is present. The next
departure then hits the `[ -z "$awaiting_lid_open" ]` guard, queues
nothing, and the panel never returns.

His journal is unambiguous — the first undock logged NOTHING (no
outputs-changed removed, no transition), then:
  14:42:31 lid-inhibitor=released      <- he opened the lid: latch cleared
  14:42:40 outputs-changed added= DP-2 <- re-dock
  14:42:47 outputs-changed removed= DP-2 transition=undock-queued
  14:42:49 transition=undock result=ok

Fix: clear the latch where undock_pending is already cleared — a new
external ends the departure the latch describes. Replaying his sequence
with the lid never opened: old = 1 of 3 undocks run, new = 3 of 3.

This is very likely #127's SECOND symptom ("unplugging did not turn the
laptop panel back on") and it has nothing to do with DPMS. Which raises the
odds that the shipped mitigation is treating the wrong cause — TEST B now
decides that, and with this fix an undock is a real escape hatch during it.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

modules/home/hyprland.nix

@@ -656,6 +656,19 @@ ${lib.concatStringsSep "\n" (lib.mapAttrsToList
           # A new external supersedes any undock still queued for an older
           # departure: the panel is about to be disabled again on purpose.
           undock_pending=
+          # …and it supersedes a *completed* one too. Bernardo 2026-07-16:
+          # undocked, panel stayed dark; re-docked and undocked again and it
+          # came back — because in between he opened the lid. `awaiting_lid_open`
+          # is set by every successful undock and cleared only when the external
+          # is gone AND the lid is open, so a clamshell undock latches it; the
+          # next departure then hits the `[ -z "$awaiting_lid_open" ]` guard
+          # below, queues nothing, and the panel never returns. His journal shows
+          # exactly that: no `outputs-changed removed` for the first undock at
+          # all, then a release the moment he lifted the lid, then a clean
+          # undock. The latch means "this departure is dealt with" — a new
+          # external ends that departure, so clear it here or it outlives the
+          # thing it describes.
+          awaiting_lid_open=
           [ -z "$internal" ] || acquire_inhibitor
           # An external output that was not there a moment ago is an
           # unambiguous physical plug whether or not we saw the IPC event,