feat: add PurchasesConfiguration.Builder.SetProxyURL

[vegaro]

The proxyURL inspector field's tooltip has always told runtime-setup users to "configure it through PurchasesConfiguration instead", but PurchasesConfiguration never had a proxy URL option, so there was nowhere to go. A developer using runtime setup would read that, look for the option, not find it, and reasonably conclude proxy URLs aren't supported for runtime setup.

Adds PurchasesConfiguration.ProxyURL and Builder.SetProxyURL(string).

Configure forwards it to the wrapper before calling Setup, since the native SDKs need the proxy in place before they're configured. It's only forwarded when set. That guard matters for more than tidiness: an unconditional call would pass null for every configuration without a proxy URL and clear one that had already been set through the inspector field in Start.

Also fixes the tooltip, which was wrong twice. It claimed the value "will be ignored if Use Runtime Setup is true", but Start applies it at Purchases.cs:119-121, before the if (useRuntimeSetup) return; on line 124. It takes effect on both paths, and now the pointer to the builder is accurate too.

That note is shared boilerplate across 8 inspector fields, and it is correct for the other 7: the API keys, useAmazon, autoSyncPurchases, appUserID, productIdentifiers, userDefaultsSuiteName and purchasesAreCompletedBy are all read inside Configure or below the early return, so runtime setup really does skip them. proxyURL is the only field applied above it, and it looks like the note was just inherited from its neighbours. Git history backs that up: the proxyURL block was added in #25 before runtime setup existed, has one commit in its whole history and has never moved, while useRuntimeSetup arrived later in #118 and the note later still in #125. So the note was already false when it was written, rather than being made stale by a refactor. That is also why the new wording leads with "unlike the other fields here".

Known inconsistency, deferred to the next major

This PR does not make proxyURL behave like its neighbours, and that is on purpose.

proxyURL stays the one inspector field runtime setup does not ignore. The consistent version would move it below the if (useRuntimeSetup) return;, so that runtime-setup apps had to use Builder.SetProxyURL and the original boilerplate note became true. I did not do that here because it silently breaks a working setup: anyone using runtime setup together with the inspector field has a working proxy today, and after such a change their traffic would go straight to RevenueCat's default endpoints with no error and no log line. Proxy URLs are handed out to customers who proxy for egress control, compliance or regional routing, so silently bypassing it is worse than failing loudly.

There is also a wrinkle that makes the "consistent" version less clean than it sounds. The proxy has to reach the native SDK before configure, and for inspector-configured apps Start is the only place that can happen, so the current placement is the one spot that serves both paths. Moving it down would make the inspector field dead for runtime setup unless Configure fell back to reading it, which would mix inspector state into a runtime configuration object.

So the alignment is deferred to the next major, alongside #1018, which is the same family of inspector-path versus runtime-path divergence. There is a comment at the application site in Start recording this, so it does not read as an oversight.

Parity

No native or purchases-hybrid-common change is needed. CommonFunctionality.proxyURLString and setProxyURLString (common.kt:876) already exist on both platforms, and all three Unity wrappers already implement SetProxyURL. This also matches Android, where proxyURL lives on the configuration builder rather than being a separate static.

Behavior change

None for existing apps. This is additive: the new field defaults to null, and a configuration that doesn't set it behaves exactly as before, including leaving an inspector-set proxy URL alone.

Tests

• PurchasesAPITests exercises SetProxyURL and reads ProxyURL back, for compile-time API stability.
• BuildUsesBuilderDefaults asserts the default is null; BuildUsesConfiguredValues asserts it round-trips.
• ConfigureSetsProxyUrlBeforeSettingUp pins the ordering, not just that both calls happen.
• ConfigureWithoutProxyUrlDoesNotCallSetProxyUrl pins the guard.

The last two were mutation-tested against the real runner. Each mutation failed exactly the intended test and nothing else:

Mutation	Result
Delete the SetProxyURL call	ConfigureSetsProxyUrlBeforeSettingUp fails, invocation count 2 to 1
Remove the guard	ConfigureWithoutProxyUrlDoesNotCallSetProxyUrl fails, count 1 to 2
Call it after Setup	ConfigureSetsProxyUrlBeforeSettingUp fails, first invocation was Setup

Removing the guard also breaks the pre-existing ConfigureForwardsEveryConfigurationValue, which is the other reason it's there.

Verification

• test-edit-mode locally on Unity 6000.2.6f2: 23/23 passed, 0 failed, 0 skipped, and 23/23 again after restoring from the mutation runs.
• scripts/check-meta-files.sh
• CI