ph_scoped_capture stamps region='US' on every event regardless of instance region

Bug

ph_scoped_capture() in posthog/ph_client.py stamps region='US' on every event it captures, regardless of which instance the worker is actually running on.

Mechanism:

• get_client(region: str = "US", **kwargs) conflates two different things in its single region parameter: where events are sent (it selects the API key/host) and what events say (it sets super_properties={"region": region}).
• ph_scoped_capture() calls get_client() with no arguments, so the scoped client is always built with super_properties={"region": "US"}.
• Sending to the US key is correct for all instances - that is the intended destination for this internal telemetry. The bug is only the label: events captured from EU (or dev) workers arrive mislabeled as region='US'.

The global client in posthog/apps.py handles this correctly: it uses the US key as the destination but stamps super_properties={"region": get_instance_region(), ...}. That's why events captured via module-level posthoganalytics.capture carry correct US/EU/DEV region labels while everything captured through ph_scoped_capture (Celery-task analytics, e.g. the signals scout auto-pause sweep events) does not.

Downstream effect: any per-region breakdown of ph_scoped_capture-emitted events reads 100% US, and region attribution has to be reconstructed via joins instead of reading the property.

Proposed fix

Keep the destination exactly as it is (US key/host), but stamp the actual instance region on the scoped client's events:

• In the scoped-capture path, set super_properties={"region": get_instance_region() or "US"} (matching the global client's behavior in posthog/apps.py; optionally match its service/environment stamping too for parity).
• get_client("EU") is NOT the fix - that swaps the API key/host and would reroute events to a different destination project entirely. Only the label should change, never the destination.
• Add a test asserting the scoped client's region super property follows get_instance_region() (and still falls back to US when the region is unset), and that the US key/host are used regardless of instance region.

Note for consumers: after this deploys, only new events carry the correct label - historical events remain mislabeled, so any analysis spanning the fix date still needs join-based region attribution.

In posthog/ph_client.py, inspect get_client and ph_scoped_capture, then compare their region handling with the global client in posthog/apps.py. Add a test covering the instance region and the fallback when it is unset, while verifying the US destination remains unchanged. Done means scoped events carry the correct region label without changing their destination.