[Epic]: SCIM 2.0 provisioning and de-provisioning

## Summary
Add SCIM 2.0 provisioning and de-provisioning so enterprise IdPs (Okta, Entra ID) can create, update and deactivate lightbridge accounts automatically, instead of platform admins managing 10,000 users by hand.

## Intent / Source of truth
Manual user management is untenable at 10k seats, and de-provisioning-on-offboarding is a control auditors check, not a convenience. Every surveyed competitor (Copilot/GHEC, Cursor Enterprise, Windsurf, Tabnine, Sourcegraph — the last "experimental") ships SCIM. Its absence is a disqualifying RFP gate. Source: 2026-08-13 competitive/enterprise-readiness research pass (no prior tracking issue existed).

## Scope
- [ ] SCIM 2.0 Users endpoint (create, read, update, deactivate) per RFC 7644
- [ ] SCIM 2.0 Groups endpoint mapped to lightbridge teams/org nodes
- [ ] De-provisioning semantics wired to budget and API-key revocation
- [ ] IdP conformance testing against Okta and Entra ID

## Out of scope
- Just-in-time (JIT) provisioning via SAML assertions (separate future epic if needed)
- Non-SCIM custom HRIS integrations

## Verification
Conformance test suite passing against both Okta's SCIM validator and Entra ID's provisioning test connection; a deactivated SCIM user has zero standing API keys and zero budget allocation within one provisioning cycle.

## Risk assessment
Incorrect de-provisioning could leave stale credentials active (security risk) or over-eagerly revoke active sessions (availability risk); both need explicit test coverage before rollout.

## AI Usage Declaration
Drafted with AI assistance during the 2026-08-13 cross-repo backlog consolidation and enterprise-readiness research. A human owns intent, verification and consequences.

Start by locating the SCIM Users and Groups endpoint entry points in the Rust auth service, then read the budget and API-key revocation paths. Use RFC 7644 and the Okta and Entra ID provisioning tests as the first verification targets. Done means both conformance checks pass and deactivated users have zero standing API keys and budget allocation within one provisioning cycle, with explicit coverage for credential and session risks.

Escrito por el modelo de indexación a partir del texto del issue.