acpi: ignore wake button press replayed by firmware on resume

Some firmware delivers the power or sleep button press that woke the
system as an ordinary button press (Notify 0x80) shortly after resume,
rather than as the wakeup notification (Notify 0x02) the ACPI
specification requires for a button that is also a wake source.

On affected machines (e.g. the Framework Laptop 12, Intel Raptor Lake-P)
the power button is a control-method device behind the embedded
controller. The EC latches the key press that woke the system across the
sleep transition and flushes it through its normal _Qxx query path as
soon as it is reinitialized on resume. The replayed press is
indistinguishable from a genuine one, so the kernel honors it as a fresh
suspend request and the machine suspends again immediately after waking;
it cannot be kept awake with the button.

The event cannot be filtered at its source: it arrives over the same EC
query path that also carries legitimate events (lid, AC, thermal,
battery), so suppressing the drain would lose real notifications.
Instead, record the time of resume and ignore a button-initiated suspend
that arrives within a short grace window of it. The timestamp is taken
before DEVICE_RESUME() re-initializes the EC, so it is set before the
replay can be processed on the ACPICA notify taskqueue; otherwise the
replay can be evaluated before the timestamp is written and slip through.
Measured from that point, the replay lands at ~600 ms across many cycles
on a Framework Laptop 12, whereas a deliberate press cannot occur that
quickly -- it happens well after the display is back -- so a one-second
window separates the two without ignoring real presses for any
perceptible time.

Spec-compliant firmware reports the wake as Notify 0x02, which is handled
on a different path and never reaches this check, so there is no change
in behavior on such systems.

The replay window is a fixed compile-time constant rather than a tunable
on purpose: it tracks a hardware characteristic -- the EC's post-resume
replay latency -- not a user policy, so there is no value a user would
meaningfully choose.

PR: 296243
Reviewed by: adrian, imp (earlier revision), olce
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D57712