fix: resolve rate-limit proxy IP collapse and JSON log injection

[luis5tb]

Rate limiter: enable uvicorn proxy header trust (X-Forwarded-For) so each client gets its own bucket behind GCLB/OpenShift Routes instead of all tenants sharing a single proxy-IP bucket. Reorder Auth before RateLimit middleware on the agent service so tenant-based bucketing (order/user/client) is active — the multi-dimensional principal resolution was dead code when rate limiting ran before auth.

JSON logging (CWE-117): replace %-format JSON templates with pythonjsonlogger JsonFormatter so user-controlled content in log messages cannot break JSON structure or inject fake fields.

[IlonaShishov]

Code Review — Issues

1. Security trade-off of reordering: unauthenticated floods no longer throttled at IP level before auth

The old comment explicitly noted: "runs before auth so unauthenticated floods are throttled at the IP level before any auth processing." By moving rate-limit after auth, every unauthenticated request now passes through the full JWT validation pipeline before being throttled. This means:

• An attacker sending floods of invalid tokens will consume JWT validation resources (SSO introspection calls, crypto verification) before hitting rate limits
• The proxy IP collapse was a real bug, but the original ordering was a deliberate defense-in-depth choice

Consider whether a two-layer approach is better: a lightweight IP-based pre-auth throttle (e.g., connection-level via Cloud Armor / nginx) plus the current tenant-based post-auth throttle. The CLAUDE.md notes Cloud Armor is already in the Cloud Run deployment — does it cover this gap?

2. forwarded_allow_ips: str = "*" trusts all proxies by default

The * default means any X-Forwarded-For header is trusted, even from direct clients not behind a load balancer. This is fine when ingress is restricted to the load balancer (Cloud Run, OpenShift Routes), but in Podman/dev mode where there's direct port binding, an attacker can spoof X-Forwarded-For to evade IP-based rate limiting.

The field description says "safe when ingress is restricted to the load balancer" — consider defaulting to "" (disabled) or the GCLB IP ranges, and only enabling in deployment configs.

3. Marketplace handler uses os.getenv instead of Pydantic settings

The agent service added proxy_headers and forwarded_allow_ips to the Settings model with validation, but the marketplace handler reads them via raw os.getenv:

proxy_headers=os.getenv("PROXY_HEADERS", "true").lower() == "true",
forwarded_allow_ips=os.getenv("FORWARDED_ALLOW_IPS", "*"),

This bypasses the Pydantic validation. It's consistent with how the handler already reads LOG_LEVEL/LOG_FORMAT (also raw os.getenv), so it follows precedent, but it's a divergence worth noting.

4. Duplicate if log_format == "json" check in marketplace handler

if log_format == "json":
    from pythonjsonlogger.json import JsonFormatter
    handler.setFormatter(...)

if log_format == "json":           # <-- second check, same condition
    logging.basicConfig(level=log_level, handlers=[handler])
else:
    logging.basicConfig(...)

These two blocks should be a single if/else. The same pattern appears in the agent's main.py.

5. Stderr → stdout change in marketplace handler

The diff adds import sys and StreamHandler(sys.stdout). The old code used logging.basicConfig() which defaults to stderr. This silently changes marketplace handler logs from stderr to stdout. If intentional, worth a note in the PR description.

[IlonaShishov]

lgtm