tracking: support explicit carrier_id and test_mode selection

[HansDaigle]

Summary

• Add carrier_id and test_mode to TrackingData for tracking POST APIs.
• Forward those selectors to carrier resolution in:
  • POST /v1/proxy/tracking
  • POST /v1/trackers

Why

When multiple connections exist for the same carrier, tracking should be able to deterministically target a specific connection/mode, consistent with shipping connection selection behavior.

Tests

• Added proxy tracking test to assert carrier_id and test_mode are forwarded to Shipments.track.
• Added manager trackers test to assert selectors reach Connections.first in serializer flow.

Validation

• Syntax checked with py_compile for changed files.

[vercel]

@HansDaigle is attempting to deploy a commit to the karrio Team on Vercel.

A member of the Team first needs to authorize it.

[danh91]

Review

The feature direction is right. When a user has multiple connections for the same carrier — two DHL accounts, one domestic and one international — tracking currently has no way to pin to a specific connection at call time. Shipping, pickups, and rates all support carrier_id selection already, so this is a genuine consistency gap and worth closing.

That said, there are two things to address before this can land.

---

Drop test_mode from TrackingData

test_mode is already handled by the API token and auth context. When an API key is scoped to test mode, request.test_mode is set to True, and Connections.first() already reads it:

test_mode = list_filter.get("test_mode") or getattr(context, "test_mode", None)

Adding it to the request body creates a second control surface for the same thing, with ambiguous precedence and a real security implication: the current implementation lets the body value win, which means a production API key with test_mode=True in the payload silently resolves against test-mode carriers. That's backwards. The API token and the X-Karrio-Test header are the right mechanisms — the request body shouldn't override authentication context.

---

Move the carrier_id forwarding into the serializer

For the POST /v1/trackers flow, you've put the forwarding in the view:

if data.get("carrier_id"):
    carrier_filter["carrier_id"] = data["carrier_id"]

But TrackingSerializer already declares carrier_id as a field — it lives in validated_data. The view shouldn't need to know that carrier_id exists and manually forward it; the serializer's own create() should handle it:

carrier_filter = {
    **validated_data["carrier_filter"],
    **(
        {"carrier_id": validated_data["carrier_id"]}
        if validated_data.get("carrier_id")
        else {}
    ),
}

This keeps the view lean and the behaviour self-contained — consistent with how TrackingSerializer already manages its own carrier_filter assembly. The proxy endpoint (/v1/proxy/tracking) is a different case since it calls Shipments.track directly, so view-level forwarding is correct there.

---

Rebase

This branch has diverged heavily from main — the 4000+ file diff is all drift. The manager serializer and proxy view have both changed substantially since this was opened. A rebase before the next push will surface any real conflicts and make the actual change visible.

Once rebased, the functional diff should be small: carrier_id on TrackingData, the forwarding in the proxy view, and the serializer-level merge in TrackingSerializer.create(). That's a clean, focused change with a clear path to merge.