Allow opting out of the init-time commerce (GetSKUs) API call

[allister-beamable]

Summary

BeamContext initialization triggers GET /basic/commerce/skus on every player session. Games that do not use the commerce subsystem still pay for this call in their pay-as-you-grow API quota, with no first-class way to suppress it.

Current behavior

BeamContext.SetupPurchaser resolves IBeamablePurchaser and calls Initialize on it. The SDK self-registers UnityBeamablePurchaser, whose Initialize calls PaymentService.GetSKUs() before checking whether any SKUs are configured. So even with zero SKUs configured, the API call fires once per session.

Workaround that exists today

Customers can replace the SDK's purchaser registration with the SDK-supplied DummyPurchaser via a [BeamContextSystem]:

[BeamContextSystem]
public static class DisableCommerceInit
{
    [RegisterBeamableDependencies(order: 1000)]
    public static void RegisterServices(IDependencyBuilder builder)
    {
        builder.RemoveIfExists<IBeamablePurchaser>();
        builder.AddSingleton<IBeamablePurchaser, DummyPurchaser>();
    }
}

This works, but it is undocumented and requires customers to know about DummyPurchaser, the RegisterBeamableDependencies order field, and the difference between "no SKUs configured" and "purchaser unregistered."

Proposed

A first-class configuration toggle - either on BeamContextConfiguration or via a project-settings flag - to suppress this init-time fetch:

• skipCommerceInit (or equivalent): when true, register DummyPurchaser automatically; do not call GetSKUs.

Why this matters

Per-customer the cost is modest (rough order: pay-as-you-grow customers running ~1M+ sessions/month pay tens of dollars/month for this call), but the pattern is broad: any game that initializes BeamContext without using commerce pays for traffic it cannot control without DI tricks. The fix is a clean, low-risk SDK addition with a known opt-out code path already in place.

Related

The mail portion of this issue was split out into #4623, since the dominant driver of init-time mail traffic turned out to be the social/friends system rather than direct mail use.

[cdhanna]

I think the real issue is that the BeamContext will always try to initialize the purchaser by running this function,

async Promise SetupPurchaser()
{
	if (ServiceProvider.CanBuildService<IBeamablePurchaser>())
	{
		var purchaser = ServiceProvider.GetService<IBeamablePurchaser>();
		Promise<Unit> promise = purchaser.Initialize(ServiceProvider);
		await promise.Recover(err =>
		{
			Debug.LogError(err);
			return PromiseBase.Unit;
		});
		ServiceProvider.GetService<Promise<IBeamablePurchaser>>().CompleteSuccess(purchaser);
	}
	else
	{
		ServiceProvider.GetService<Promise<IBeamablePurchaser>>().CompleteSuccess(new DummyPurchaser());
	}
}

This can remain the default for now, but we need a config level switch that can opt folks out of init'ing the purchaser on boot.

The mail part is less knowable right now.

[cdhanna]

The mail itself is only ever updated automatically via the friends subsystem. So maybe if the customer is using the friends system, they see mail, and don't realize mail is a dep of friends.

[allister-beamable]

Moved the Mail-related stuff to #4623