build-rpms and build-container call depchase to determine which rpm(s) need to be /app-built for the given flatpak. When deciding which packages are already included in the runtime (and therefore unneeded in /app), afaics it looks for the latest container in f39-flatpak-updates-candidate. While that would get the most recently built runtime before it is queued into an update, once included in a pending or testing update it is ignored, and the latest stable release is considered instead:

$ koji list-tag-inheritance f39-flatpak-updates-candidate
     f39-flatpak-updates-candidate (70611)
....  └─f39-flatpak-updates (70610)
....     └─f39-flatpak (70609)

This is currently breaking builds of (some?) flatpaks, as https://bodhi.fedoraproject.org/updates/FEDORA-FLATPAK-2023-6ee4811e75 (currently in testing) includes a bunch of RPM updates that went stable after the final freeze was lifted, where the previous stable build predates that, and the changes are significant.

I'm not sure if the tag inheritance should be changed here, or f-m-t's logic. In the meantime, I've retagged the testing build into candidate to unblock builds.