feat(sso): auto-provision routed OAuth users

[vgunjic]

🔗 Epic / Issue

Closes #5306

---

🚀 Summary

JIT-provisions missing users during OAuth-enabled virtual-server MCP authentication by reusing ContextForge's trusted SSO provider path. The provider's existing email_claim mapping now selects the same local principal for browser SSO and MCP OAuth flows.

---

📏 Reviewability

• This PR has one clear purpose
• The linked issue is not labeled triage
• Unrelated behavior, including customized permission-error responses, is excluded
• Tests are included with the code they validate

---

🧪 Checks

• Affected unit suites pass for OAuth authentication, SSO provisioning, claim normalization, and external IdP authentication
• Changed-line coverage is 100% (diff-cover, 79 executable lines)
• Pinned Black, Ruff, Pylint, Bandit, and Interrogate checks pass for changed production code
• git diff --check passes
• Full parallel suite: one pre-existing Hypothesis 200 ms deadline check was timing-sensitive (261 ms initially, 172 ms on replay); it passed when rerun in isolation
• CHANGELOG not updated; release changelog entries are maintained with release preparation

---

📓 Notes

Provisioning remains disabled unless SSO_API_TOKEN_AUTH_ENABLED=true. It also requires an enabled provider matched by verified issuer with both trusted_for_api_auth=true and auto_create_users=true.

The shared SSO path continues to enforce email verification, trusted domains, admin approval, account linking, role mapping, and team mapping. A configured email_claim is authoritative and fails closed when missing or invalid rather than falling back to a contact-email claim. Existing and disabled local-user behavior is unchanged.

This also persists email_verified_at after the shared SSO verification gate accepts a newly created or linked user.