feat(auth): make platform login pluggable and add LDAP backend

## Summary
Enterprise users often have only AD/LDAP available for user authentication. We should make platform login pluggable so LDAP can be added cleanly without rewriting API auth paths.

## Problem
`/api/auth/login` is currently coupled to password auth in `services/api/platform_auth.go` (`AuthenticatePassword`).

## Proposal
Introduce a pluggable login provider abstraction and ship LDAP as an optional backend.

## Scope
- Add a `LoginProvider` interface and provider registry in `services/api`.
- Refactor `handleLogin` to authenticate through the configured provider(s) instead of hardcoding password auth.
- Keep request auth middleware unchanged (`x-api-key`, user API keys, platform JWT, OIDC JWT).
- Generalize identity upsert in `platform_store` for external providers (provider/subject-based mapping via `auth_identities`).
- Add LDAP provider (optional) with:
- LDAPS or StartTLS
- bind + user search
- group lookup and mapping to platform role (`user`/`admin`)
- clear failure/audit logging paths
- Add config/env validation for LDAP settings.

## Non-goals
- Replacing grants/sessions authorization model.
- Removing current password login flow.

## Acceptance Criteria
- Login works with existing password backend with no behavior regression.
- Login works against configured LDAP directory.
- LDAP-authenticated users receive platform JWT and can use existing runtime APIs.
- Provider identity is persisted using `auth_identities(provider, subject)`.
- Unit tests cover provider selection, login flow, and LDAP error cases.
- Docs updated for new auth config and rollout guidance.