fix: relax over-strict Okta SDK models that reject valid API responses

[jackvaughanjr]

Supersedes #102, which patched two of these four inline in policies.py. Closing that in favour of this.

Four generated Okta SDK models are stricter than the API they describe. Each one aborts an entire response, so a single non-conforming record makes a whole page unreadable. They are all in the pinned okta==3.4.4 dependency, so they cannot be fixed in this repo directly; they have to be relaxed at runtime.

	Model	Problem
A	SamlApplicationSettingsSignOn	Five required StrictBool fields the API omits on apps created from OIN catalog templates. Breaks list_applications, list_group_apps, and get_application.
B	Policy.embedded	Typed Dict[str, Dict[str, Any]], but Okta returns scalars inside _embedded, e.g. {"resourceType": "APP"}. Breaks list_policies(type="ACCESS_POLICY").
C	AuthenticatorEnrollmentPolicyAuthenticatorSettings.key	Closed enum missing smart_card_idp. Breaks list_policies(type="MFA_ENROLL") on any tenant using PIV/CAC.
D	UserTypeCondition.exclude/.include	Required lists where Okta sends null. Breaks list_policy_rules.

Approach

One module, okta_mcp_server/utils/okta_compat.py, applied at import time from server.py. This is the technique already used in this repo for LogSecurityContext.user_behaviors in system_logs.py; that patch is migrated into the new module so all SDK compatibility lives in one place.

Each patch is individually wrapped, so a future SDK version that removes a field logs a warning instead of breaking startup. Each carries the upstream issue that would make it removable.

Two deliberate choices worth review:

• key is relaxed to Optional[str] rather than adding one enum member. Adding smart_card_idp alone would break again on the next authenticator Okta ships. This matches the approach in fix: relax two SDK model gaps blocking list_policies on Okta for Government tenants #102.
• Only named fields are touched. Nothing sets extra="allow" and no model is blanket-relaxed. Request models keep their required-field validation, where a local error is more useful than an opaque API 400.

Pydantic v2 detail: each subclass builds its own model_fields at class-creation time, so patching Policy alone does not fix AccessPolicy. The patch names subclasses explicitly and rewrites __annotations__ so it works regardless of import order. There is a test that runs both orders in subprocesses.

Testing

26 tests, 10 synthetic fixtures (example.invalid hosts, fake IDs). Each defect has a test that fails before the fix with the exact upstream error signature and passes after. Control fixtures assert the happy path is unchanged: a populated assertionSigned: true stays True, an explicit {"exclude": [], "include": []} stays [] rather than becoming None, and SAML_2_0 still routes to SamlApplication.

Missing booleans deserialize to None, not False. For a security review, "not reported" and "not signed" must not be confusable.

Full suite: 555 passed, up from 529 on main.

Upstream

• list_applications produces pydantic validation errors for SamlApplication okta-sdk-python#546 (A, open; PR #542 fixed 10 of 16 required fields in v3.4.3 and left these 5)
• UserTypeCondition.exclude/.include reject null, but the API returns null — one policy rule aborts the whole list_policy_rules page okta-sdk-python#572 (D, open)
• list_policies(type="ACCESS_POLICY") fails: _embedded.resourceType returned as string, Policy model expects dict #100 (B), list_policies(type="MFA_ENROLL") fails on smart_card_idp: enum missing from AuthenticatorEnrollmentPolicyAuthenticatorType #101 (C), Pydantic validation errors block listing/retrieving Okta App Catalog SAML apps and Atlassian SWA apps; single bad record poisons entire response page #48 (A)

v3.4.4 is the latest release, so there is no version bump that resolves any of these.