fix(auth): scope lockout key to (account, IP) to prevent DOS by login flood (#323)

[SAY-5]

Closes #323.

What

Change the LoginLockoutService cache key from username to
username|ip. A flood of bad passwords from one IP locks that IP
out of that account; legitimate users coming from a different IP
are unaffected.

Why

The cache previously keyed on username only, so anyone who could
reach /api/auth/login and guess (or enumerate) a username could
lock that account out for the full lockout window. The reporter
demonstrated a complete DOS using X-Forwarded-For spoofing with
OXICLOUD_TRUST_PROXY_HEADERS=true:

$ curl -H "X-Forwarded-For: 1.1.1.1" \
       -d '{"password":"wrong","username":"admin2"}' \
       /api/auth/login
{"status":"429 Too Many Requests","error":"Account temporarily
 locked due to too many failed attempts. Try again in 900 seconds.",
 ...}

Every later request from any other IP for admin2 was rejected for
the next 15 minutes — full DOS for that account. The IP-based rate
limiter doesn't help: it caps requests per IP, but the per-account
counter is incremented on every IP's first few attempts before the
limiter clamps each one.

Changes

• LoginLockoutService::{check, record_failure, record_success}
  now take client_ip as a second argument; cache key is built via
  Self::key(username, client_ip) →
  format!("{username_lower}|{client_ip}").
• middleware/rate_limit.rs: factor extract_client_ip into
  extract_client_ip_from_parts(&HeaderMap, Option<&SocketAddr>)
  so handlers that consume the body via Json<…> (and therefore
  can't take a full Request<B>) can still derive the same client
  identifier. extract_client_ip now delegates to it.
• auth_handler.rs login: derive client_ip from the request
  headers and pass it to check / record_failure /
  record_success.
• nextcloud/basic_auth_middleware.rs: same wiring through
  extract_client_ip(&request), which already had Request
  access.

Tests

• All 4 pre-existing unit tests in login_lockout_service.rs
  threaded with an IP1 constant — behaviour unchanged.
• does_not_lock_out_other_ips_for_same_account (regression):
  attacker from IP1 locks the account for IP1, but check
  for IP2 against the same account stays Ok.
• success_resets_only_the_acting_ip: a successful login from
  IP2 does NOT clear an in-progress brute-force from IP1.

Verification

• cargo build ✅
• cargo test login_lockout → 6 passed.

Notes / non-goals

• Reviving the original behaviour (lock the account globally) for
  ops who explicitly want it is out of scope here. If desired, that
  could be added later as an opt-in env flag — but the default must
  be safe against the issue's repro, hence per-IP scoping.
• The fallback IP value when no proxy header is trusted and no TCP
  peer is available is the literal "unknown" (same string the
  rate limiter uses), which degrades gracefully to per-account
  scoping for that one bucket — no worse than today.