Keep Google from refunding purchases when the app is closed too soon

[d4rken]

What changed

Google refunds and revokes a Play purchase that is not confirmed back to Google within 3 days. Amply confirms it as soon as it sees the purchase, but if the app gets killed right around the purchase (some phones kill background apps aggressively) and is never reopened before the deadline, the confirmation never happens: the user pays, then quietly loses the upgrade.

The Play build now runs that confirmation in the background too, even if the app is never opened again. It re-tries over the whole 3-day window and stops on its own once everything is confirmed. Nothing changes for the FOSS build.

Technical Context

• SEMANTIC port of General: Keep Google from refunding purchases when the app is closed too soon sdmaid-se#2685 at f6f5c5e03. Amply's billing stack is a different shape (BillingManager owns its own scope instead of taking an injected one, pending purchases are filtered at the ack-pass call site, tests use hand-written fakes rather than a mocking framework), so this is behaviour parity, not file parity.
• Wiring amply gains: androidx.hilt:hilt-work + its KSP compiler, AmplyApp implements Configuration.Provider with an injected HiltWorkerFactory, the androidx.startup WorkManagerInitializer is removed from the manifest so that configuration is actually used, and WorkManager becomes injectable (WorkManagerModule). SettleRefreshWorker stays a plain worker on purpose: HiltWorkerFactory delegates workers it doesn't know to WorkManager's default reflective factory.
• Two separate unique-work identities, …purchase-ack.launch.v1 (REPLACE, 30min delay, armed and awaited before the Play sheet opens) and …purchase-ack.rescue.v1 (KEEP, 1min delay, armed pre-attempt whenever an ack pass finds unacknowledged purchases). Separate so a new purchase flow can never displace a rescue armed for a purchase that already exists. Both arms are fail-open — a broken WorkManager must never block a purchase or an ack.
• The sweep is self-completing: nothing cancels the work from the foreground, because an ack pass can legitimately see zero unacknowledged purchases while the Play sheet is still open. The worker decides success/retry from BillingManager.ensureAllAcknowledged(), which refreshes AND acknowledges in the same coroutine — the reactive ack collector is asynchronous, so a worker cannot prove through it that its acks happened.
• Closest review points: the ack pass now runs under a mutex and returns per-outcome counts (the worker sweep and the reactive collector would otherwise race the token bookkeeping); PurchaseAckScheduler takes a Provider<WorkManager> because AmplyApp eagerly injects UpgradeSurfaceSync and with it the whole billing stack during Application field injection; and the arming call site inside UpgradeRepoGplay.launchBillingFlowInternal sits inside the busy-guard try so a failed arm still releases the guard.