fix(android): process lifecycle, foreground pushes and quick replies

[chrisnojima]

Stack 4/7 on #29650.

Why

• A reply typed in the notification shade while the app is on screen is dropped. Master's whileActive returns early in the foreground, yet the notification says "Replied".
• A foreground push never reaches Go, so it is not unboxed or acked. With background now reported about 700 ms after the last activity stops, that also covers a push arriving just after Home.
• Quick reply runs on the main thread. Go sends before checking login or message id, and swallows the send error (test(bind): failing tests for quick reply error handling #29667).
• Push work that throws leaves Go in BACKGROUNDACTIVE until the next lifecycle event.
• Other problems: background sync jobs pile up as duplicates, the seen-push set is unbounded, and share intents wait on a 500 ms poll.

What this changes

• AppLifecycleReporter replaces the previous PR's forwarder, behind a testable LifecycleBind seam. appWillExit runs only on a real finish, not on a configuration change.
• withBackgroundActive:
  • A loud push always reaches Go, and its notifier skips display while in the foreground.
  • In the background it reports BACKGROUNDACTIVE, runs the work, then in finally calls appDidEnterBackground and starts a background task if one is needed.
  • A silent push in the foreground skips Go, as on master.
• Quick reply runs via goAsync on a worker thread. It refuses when:
  • the uid can't be read
  • the uid is empty
  • the uid differs from the notification's uid
  • the message id is negative
• Housekeeping:
  • share intents are parked until JS asks
  • background sync is one unique periodic job
  • the seen-push set is capped at 100

Judgment calls

• Foreground quick replies now send. Master showed "Replied" without sending. "Replied" can still show for a failed send, because Go swallows the error (test(bind): failing tests for quick reply error handling #29667).
• A reply from a notification shown before this update is refused once. Such a notification carries no uid. It fails safely rather than posting as whichever account is current.
• withBackgroundActive returns Go to the background even when the work throws. That is one extra compaction on a rare error path, rather than Go staying in BACKGROUNDACTIVE indefinitely.
• A foreground loud push is now unboxed and acked, with display suppressed, and marked seen. Master neither showed nor acked it.
• Kotlin never calls setAppStateBackground. appDidEnterBackground already does, so master's second flush is gone.
• JS sees "background" twice on exit (activity destroy, then process ON_STOP). The second is a no-op.

Tests

• WithBackgroundActiveTest covers:
  • a foreground push, with display suppressed
  • background ordering, with no second background report
  • the app opened during a push
  • silent pushes, in the foreground and in the background
  • throwing work
• SendQuickReplyTest covers each refusal.
• AppLifecycleReporterTest, RunReceiverWorkTest and BackgroundSyncScheduleTest also run.

The guards were mutation-checked.