Next Alarm sensor drops correct trigger time when creatorPackage resolves to "unknown", even with empty allow-list

## Description

The `next_alarm` sensor only updates to the correct value a few seconds/minutes before
the alarm actually fires, even though `AlarmManager.getNextAlarmClock()` already has the
correct trigger time available well in advance (confirmed via logcat, see below).

This happens consistently across different alarm apps: Samsung Clock and Sleep as Android
(com.urbandroid.sleep) both show the same behavior.

## Root cause (from logcat)

`NextAlarmManager` resolves the owning app via `alarmClockInfo.showIntent?.creatorPackage`.
When the alarm is more than a few minutes away, this resolves to `null` → logged as
`"unknown"` → the update is dropped by the allow-list check, **even though the reported
trigger time is already correct**:

```
07-08 10:52:05.103 NextAlarmManager: Next alarm is scheduled by unknown with trigger time 1783518859000
07-08 10:52:05.103 NextAlarmManager: Skipping update from unknown as it is not in the allow list
...
07-08 10:54:39.037 NextAlarmManager: Next alarm is scheduled by com.urbandroid.sleep with trigger time 1783518900000
```

Note: `1783518859000` / `1783518900000` both correctly matched the actual scheduled alarm
time at the moment they were first logged — this isn't a data-availability problem, the
correct value is present ~2+ minutes ahead, but is silently discarded because the package
can't yet be resolved.

## Made it worse: clearing the allow-list

After clearing the allow-list entirely (expecting it to accept all sources), the sensor
started reflecting what appear to be unrelated system/app-level `AlarmClockInfo` entries —
e.g. one at 11:12 local with no user-configured alarm at that time. This suggests
`getNextAlarmClock()` is picking up entries other apps register (possibly for keep-alive
purposes) that aren't genuine user-facing alarms, and an empty allow-list doesn't behave
as "accept the real alarm, ignore everything else."

## Impact

Any automation relying on "N minutes before alarm" (a documented use case for this sensor)
is unusable, since the correct value only becomes available seconds before the alarm itself.

## Environment

- Device: Samsung Galaxy S25 Ultra
- Android version: 16, security patch level May 2026
- Companion app version: 2026.6.5-full
- Alarm apps tested: Samsung Clock (native), Sleep as Android — same behavior on both

## Questions

1. Should an unresolved `creatorPackage` ("unknown") be dropped silently, or should the
sensor still update using the trigger time while just leaving the app attribution blank?
2. What's the intended behavior when the allow-list is empty — accept all, or something else?
3. Is there a way to distinguish genuine user-facing alarms from other apps' `AlarmClockInfo`
registrations used for background keep-alive?

Start by reading the NextAlarmManager entry point and tracing its use of AlarmManager.getNextAlarmClock(), then reproduce the logged unknown creatorPackage and empty allow-list cases on the described Android setup. Compare the trigger time, creator attribution, and filtering behavior in logcat; done means the intended handling is established and the next_alarm sensor reliably exposes the correct user alarm without unrelated entries.

Written by the indexing model from the issue text.