feat(models): type notification payloads per notification kind

[kartojal]

Ports DEV-459 to the Python SDK, mirroring the modeling already merged in ts-sdk.

• Notification is now a discriminated union of ten per-kind models on a new NotificationType IntEnum, each with a typed payload model instead of payload: Any.
• owner uses a new ApiKey NewType.

Linear: DEV-459

---

Note

Medium Risk
Breaking API change for consumers that relied on untyped payload or owner as str; stricter parsing may reject malformed API data that previously passed.

Overview
Replaces the loose Notification model (type: int, payload: Any) with a discriminated union of ten per-kind notification classes, keyed by a new NotificationType IntEnum, each with a typed payload (orders, markets, payouts, comments, auto-redeem, etc.).

Notification moves from account.py into notifications.py; owner is now an ApiKey NewType instead of a plain string. Public exports and tests are updated so parsing/validation fails on unknown notification types and integration checks assert NotificationType on live responses.

^{Reviewed by Cursor Bugbot for commit 54d5bc7. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 3 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit ab6464b. Configure here.}

[naruto11eth]

Approved.

quick thing: the old permissive Notification class is still in account.py:171 (with its now-unused Any import) - exports and parsing all moved to the new union, so that's two incompatible models for the same concept, and it's the one Bugbot thread still open.

Also actually curious: maker_base_fee/taker_base_fee are Optional here where both the ts twin and clob-v2 have them always present - is this intentional?