feat(allocation-policy): Per-org overrides for bytes-scanned policy

[phacops]

Add per-organization controls to BytesScannedRejectingPolicy so individual noisy orgs can be tuned without affecting every other organization.

Per-org scan-limit overrides

Two new configs override the sliding-window scan limit on the organization branch:

• organization_referrer_scan_limit_override, keyed by (organization_id, referrer)
• organization_scan_limit_override, keyed by organization_id

Overrides are resolved in order of specificity, with the first one set winning:

(organization_id, referrer)
  > organization_id
  > (all orgs, referrer)      # existing referrer_all_organizations_scan_limit_override
  > default                    # existing organization_referrer_scan_limit

Per-org max_bytes_to_read cap

Two more configs forward a hard max_bytes_to_read value to ClickHouse and bypass the sliding-window check entirely:

• organization_referrer_max_bytes_to_read, keyed by (organization_id, referrer)
• organization_max_bytes_to_read, keyed by organization_id

When set, the query is allowed to run at full threads with the cap applied; ClickHouse aborts it if it would scan more than the cap. (org_id, referrer) wins over org_id. This complements the existing global limit_bytes_instead_of_rejecting flow, which only caps queries after a tenant exceeds its scan limit.

The project branch and cross-org behavior are unchanged.

Drive-by fixes

Touching the file caused the pre-commit hook to flag pre-existing lint/mypy issues in the same files (E712 truthiness comparisons, untyped tenant_ids dicts, ResourceIdentifier arg type, and a # type: ignore that drifted off the offending line after ruff reformatted it). These are fixed in the same PR since the hook blocks otherwise.

[sentry]

Bug: The new organization-level max_bytes_to_read check runs before determining the query type, causing project-based queries to bypass their specific rate limits if an org-level cap is set.
_{Severity: HIGH}

Suggested Fix

The organization cap check should be moved to after the call to _get_customer_tenant_key_and_value(). The check should only be applied when the customer_tenant_key is confirmed to be "organization_id", ensuring it only affects organization-based queries.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: snuba/query/allocation_policies/bytes_scanned_rejecting_policy.py#L277-L292

Potential issue: The `__get_organization_max_bytes_to_read()` check is applied to any
query with an `organization_id` in `tenant_ids`. This check occurs before the logic that
determines if a query is project-based or organization-based. Consequently, for a
project-based query that also includes an `organization_id`, if an organization-level
`max_bytes_to_read` cap is configured, the function will return early with the
organization's cap. This bypasses the intended project-level sliding-window rate limits,
potentially allowing the project to scan an unlimited number of bytes beyond its
configured limit.

_{Did we get this right? 👍 / 👎 to inform future reviews.}