Search audit logs

Search audit logs by various criteria. The tenant scope is always forced from the X-Tenant-ID header (the body cannot override it); requests without the header are rejected with 401. user_email and client_id are case-insensitive partial (ILIKE substring) matches. The search start time is clamped to the tenant's tier-based retention window.

Role-scoped reads (#2922): the caller's read scope is resolved server-side. admin/owner read the full tenant trail; every other role — and any caller without a validated per-user identity — reads only their own user_email rows (fail-closed). A non-admin's user_email filter can only narrow the result to their own identity, never widen it to another user's rows. Callers without any resolvable identity receive an empty entries array. The role/scope is trusted only over the internal agent→orchestrator proxy-auth channel, never a client-forwarded header.

Single-operator deployments (#3060): DEPLOYMENT_MODE=community reads tenant-wide unconditionally, and DEPLOYMENT_MODE=community-saas reads tenant-wide for requests that arrived over the agent gateway (proven by the internal proxy-auth token) — in that mode the organization, tenant and credential are one cs_<uuid>, so tenant-wide is that single evaluator's own data. A community-saas request that reaches the orchestrator directly stays least-privilege. Read scope is a separate axis from administrative authority: a community-saas caller reads tenant-wide here and is still denied (403) the whole-tenant compliance exports and the cost/usage/execution family.

Method: this endpoint is POST-only (its criteria are a JSON body). A GET returns 405 with Allow: POST, OPTIONS.