fix(control): isolate auth rate limits behind the trusted reverse proxy #202

What happened

Stability audit finding F03 / P2 (2026-09-27). Priority is an audit recommendation, not a claim of a production incident.

The loopback-only Control server overwrites x-session-peer-ip with the socket remote address. Behind Caddy, different users therefore share the loopback identity. BetterAuth 1.7.5 keys its limiter by IP plus endpoint path.

In a local /api/auth/device/code fixture, the shared identity receives 60 successful responses followed by 429 responses. Changing the forwarded client identity does not change this bucket; a separately keyed internal identity still receives 200. This is shared quota per endpoint, not one global bucket for all auth endpoints.

What you expected

Define a sanitized, trusted proxy client-identity contract and isolate intended per-client limits while retaining abuse protection. Do not blindly trust caller-controlled X-Forwarded-For or weaken rate limiting.

Environment

• Baseline: published session-peer v1.0.1, commit 55168c3bea5a49e81916fdead57d3634def6b1d6.
• Reproduction: isolated source/tag fixtures; no live message/ACK tests or production mutation.
• Audit environments: macOS arm64, Python 3.14.7; Control tests use Node 22.14.0. Linux evidence is explicitly identified above where applicable.
• Discovery output: not applicable to this fixture; no real session identifiers or credentials are included.

Source evidence

• control/src/server/main.ts#L66
• control/src/server/auth.ts#L143

Acceptance criteria

• Requests representing independent clients behind the trusted proxy do not unintentionally exhaust each other's per-client bucket.
• Spoofed forwarding headers from untrusted sources cannot bypass limits.
• Retain endpoint-specific/global abuse limits, document proxy assumptions, and test 429 behavior.

Scope and limitations

Server-side follow-up distinct from #174's client backoff. This does not retrospectively establish the cause of historical login 429s. Control/proxy deployment is separate from Python package publication.

Target: v1.0.2 stability work. This issue does not authorize a release or operating-service changes. Offline reproduction establishes the failure mechanism, not attribution of historical #161 incidents.

Checked

• Searched existing issues for duplicates.
• Removed credentials, conversation contents, private paths and real device/session identifiers.
• Used isolated fixtures without weakening inbound permissions.