[security][P2] Per-org / per-user IP allow-list (record-level allowed_ip_ranges) — ADR-0069 D5 #2571

Remaining ADR-0069 D5 gap (P2, defense-in-depth — not a launch blocker). Surfaced by the 2026-07-04 enterprise-auth evaluation.

Current state (already landed)

• Global IP allow-list: auth.allowed_ip_ranges setting (global scope) → AuthManager.isClientIpAllowed → enforced in the auth-route middleware (auth-plugin.ts), rejecting sign-in/session from an outside IP with IP_NOT_ALLOWED. Fails open when the client IP can't be determined (missing proxy header ≠ lockout).
• IPv4 CIDR + exact IPv4/IPv6 matching via ipMatchesRange.

Gap

ADR-0069 D5/D7 also specify record-level ranges so different tenants/users can have their own IP fence:

• sys_organization.allowed_ip_ranges (CIDR[]) — per-org.
• sys_user.allowed_ip_ranges (CIDR[], optional override) — per-user.

Neither field exists today; only the one global setting.

⚠️ Design decision to lock before implementing: tighten-only, not replace

ADR-0069 D5 phrases the per-user range as "evaluated before org" — which reads like replacement (most-specific wins). That is a privilege-escalation surface: an org admin (who can edit sys_organization) or a user could set a record-level range that admits an IP the global floor forbids, bypassing the platform's network fence.

Recommendation (aligns with ADR-0007's "an org can only tighten, never loosen, the global floor"): the effective allow decision is the intersection (AND) down the chain, not replace:

allowed(ip) = matchesGlobal(ip)                         // platform floor (if set)
           AND (orgRanges  ? matchesOrg(ip)  : true)    // org may only narrow
           AND (userRanges ? matchesUser(ip) : true)    // user may only narrow

i.e. a record-level range can only remove IPs, never add one the level above rejected. Keep the existing fail-open when the IP is undetermined. This must be decided (and stated in the ADR) before writing code — it's a correctness/security call, not a detail.

Scope

• Add sys_organization.allowed_ip_ranges + sys_user.allowed_ip_ranges (CIDR[] text) fields.
• Extend the IP gate: resolve the caller's org (active org / membership) + user, evaluate the intersection chain above. The org/user resolution seam already exists (the middleware runs before better-auth; customSession knows the active org).
• Tests: global-only (unchanged), org narrows, user narrows, a record-level range that tries to widen beyond the floor is not honored, undetermined-IP fail-open.
• Update ADR-0069 D5 with the chosen semantics.

Relation

• ADR-0069 D5/D7 · [umbrella][security] 授权全生命周期缺口地图 — 包开发 → 生产上线(P0–P3) #2561 P2 (企业认证 P2) · sibling shared-rate-limit-store work (ADR-0069 D2).
• Deferred here because the 2026-07-04 launch is multi-node but not per-tenant-IP-scoped; global allow-list + shared rate-limit store cover that shape. Do this when a multi-tenant B2B customer needs per-company IP fencing.