Fix a bug where media resumption would break if prepare() was called in onCreate()

Media resumption code relied on the assumption that if no media
controller sends any commands, the player will stay in STATE_IDLE.
This optimization however breaks if a developer calls prepare()
in or shortly after (in my case, which caused this to be a race)
onCreate(). Instead, use playWhenReady to determine whether we need
to do a query with effort, because playWhenReady really shouldn't
be set to true on device bootup. :)
SystemUI asks for resumption support while a session is active and just
started playing (playWhenReady=true), hence the optimization is still valid.

Author: nift4

libraries/session/src/main/java/androidx/media3/session/MediaLibrarySessionImpl.java

@@ -166,10 +166,10 @@ public ListenableFuture<LibraryResult<ImmutableList<MediaItem>>> onGetChildrenOn
       if (!canResumePlaybackOnStart()) {
         return Futures.immediateFuture(LibraryResult.ofError(ERROR_NOT_SUPPORTED));
       }
-      // Advertise support for playback resumption. If STATE_IDLE, the request arrives at boot time
-      // to get the full item data to build a notification. If not STATE_IDLE we don't need to
-      // deliver the full media item, so we do the minimal viable effort.
-      return getPlayerWrapper().getPlaybackState() == Player.STATE_IDLE
+      // Advertise support for playback resumption. If we're not playing, the request probably
+      // arrived at boot time to get the full item data to build a notification. If we're playing,
+      // we don't need to deliver the full media item, so we do the minimal viable effort.
+      return !getPlayerWrapper().getPlayWhenReady()
           ? getRecentMediaItemAtDeviceBootTime(browser, params)
           : Futures.immediateFuture(
               LibraryResult.ofItemList(