#1494 Fix alarm displaying previous events when a second alarm arrives

[fpMiguel]

Summary

Fixes #1494. When a second alarm arrives while the alarm screen is already showing,
the screen kept displaying the previous alarm's events. The alarm activity is launched
with NEW_TASK | SINGLE_TOP (and singleInstance in the manifest), so a new alarm
while the screen is up is delivered via onNewIntent, which was never handled. The new
intent was dropped and the screen stayed on the old events.

No other behavior changes; the fix is confined to the alarm screen and its test.

Changes

• ReminderAlarmActivity: handle onNewIntent by storing the new intent and
  replacing the displayed fragment with the new alarm's data.
• AlarmFragment: replacing the fragment no longer destroys the activity. The
  finish-and-remove-task behavior (which kept the alarm out of recents) is preserved
  for actual closes, including the system back button, via an isFinishing guard.
• AlarmIntentRedeliveryTest (new, instrumented): seeds two alarms, delivers the
  second alarm's intent through the real framework entry point
  (Instrumentation.callActivityOnNewIntent), and asserts the screen switches to the
  new alarm's medicine. Without the fix this test fails with "Alarm screen should show
  the second alarm's medicine (Meds B), got: Meds A" (verified against the unfixed
  parent commit).
• RepositoryEntryPoint (new, test-only): Hilt entry point for seeding test data
  directly, matching the existing entry-point pattern.

Note: open PR #1504 proposed a similar fix without a regression test and without the
fragment-lifecycle handling; this PR covers both.

Testing

• Regression test: fails on the unfixed parent commit (RED, bug reproduced), passes on
  this branch (GREEN).
• Instrumented regressions: NotificationTest notificationTest, alarmTest,
  automaticallyTakenTest: 3/3 pass.
• JVM unit suite: 132 tests, 0 failures.
• Lint: clean.

AI was used to create this pull request

[Futsch1]

This is a tricky one. I also tried to fix it (see #1504), but the behavior of Android differs between SDK 28 and SDK 36. So I guess the fix needs to check SDK versions and specifically find out which version changed the behavior.