feat: add Experiment Center override params to AuthorizationParameters

[nandan-bhat]

Summary

This PR adds the Auth0 Experiment Center override params (experiment_id, variation_id, segment_id) to interactive login, for parity with the other Auth0 SDKs.

By default Auth0 assigns each user to an experiment variation automatically. Passing these params on a login call forces a specific experiment, variation, or segment, which helps when you want to reproduce a variation while debugging. The override applies to that one login request only.

Changes

• auth_types/__init__.py: added experiment_id, variation_id, and segment_id as optional str fields on the AuthorizationParameters model.
• tests/test_server_client.py: added test_start_interactive_login_forwards_experiment_center_params, which checks that all three params reach the /authorize request.
• examples/InteractiveLogin.md: added an Experiment Center Overrides section that shows how to pass the params per login call.

How it works

start_interactive_login already forwards any extra authorization_params to the/authorize URL, because these keys are not in the INTERNAL_AUTHORIZE_PARAMS denylist. The new fields just explicit and typed. This is an additive, non-breaking change.

Testing

• poetry run pytest: 611 passed.
• poetry run ruff check .:

Note

These are both pre-existing and deliberately left out of this surgical commit:

1. The other InteractiveLogin.md examples call start_interactive_login({...}) with a raw dict, which does not match the code, since it reads options.authorization_params as an attribute. The new section uses the correct StartInteractiveLoginOptions(...) form.
2. AuthorizationParameters is vestigial. It is defined but never instantiated or used as a type, so these new fields are for parity only. It should be wired in or removed in a later change.

[cschetan77]

LGTM. Could we also add a short section in README (referencing to the example provided)

[kishore7snehil]

One design thing worth noting. This model defines the params as typed fields, but the login path reads authorization_params as a plain dict, so the typed fields here don't actually flow into the call path or give type checking at the call site. I see you already called this out in the PR description as a known gap, so I'm not asking to change it in this PR.

Is dict the intended shape for now?

[nandan-bhat]

Yes, dict is what we want for now.

The typed fields on AuthorizationParameters are only there for parity and to help discovery.
The login path still reads authorization_params as a plain dict. I didn't want to change this pattern in this PR as this is a pre-existing pattern in this SDK.

[nandan-bhat]

LGTM. Could we also add a short section in README (referencing to the example provided)

Addressed in f2eb2f6

[kishore7snehil]

LGTM!