Add proposals for client-identity rate limiting (write and query paths)

[krunaljain]

What this PR does

Adds two companion design proposals to docs/proposals/:

• client-identity-rate-limiting.md: proposes a second, optional rate-limiting dimension below the tenant on the write (ingestion) path, keyed on a new trusted X-User-ID header, following the same trust model Cortex already uses for X-Scope-OrgID.
• client-identity-query-rate-limiting.md: a companion follow-on applying the same identity mechanism to query-frontend rate limiting on the read path.

Motivation

Cortex enforces ingestion and query limits at the tenant level only. In practice a single tenant is often shared by multiple independent services or teams, and today's limiters cannot distinguish a well-behaved writer/querier from a noisy or misbehaving one sharing the same X-Scope-OrgID. These proposals add an opt-in, additive mechanism to throttle by client identity below the tenant, without changing existing tenant-level behavior for anyone who doesn't configure it.

Both proposals are:

• Fully opt-in and backward compatible (disabled by default; zero behavior change unless explicitly configured).
• Additive to, not a replacement for, existing tenant-level limits.
• Scoped with explicit rollout plans (introduced as experimental features, phased local-then-global enforcement).

Design highlights

• Identity comes from a new, generic, gateway-set X-User-ID header, trusted the same way Cortex already trusts X-Scope-OrgID (i.e. no new authentication mechanism is introduced).
• Per-client tracking is bounded via least-recently-used eviction (matching Cortex's existing tenant-federation regex-resolver cache pattern), rather than an unbounded map, to avoid a memory-growth/DoS vector.
• The write-path and query-path proposals share the same identity mechanism and header, but are kept as two separate documents given their different enforcement points (distributor vs. query-frontend) and to keep review scope focused.

Status

Both are filed as proposals for discussion (Status: Proposed). No code changes are included in this PR; implementation would follow as separate PRs once the design is reviewed.

Checklist

• Docs-only change; no code, tests, or CHANGELOG entry needed.
• Commit signed off (DCO).