feat(allocation_policies): per-tenant attachment via match blocks

[pbhandari]

Stacked on #8387. Linear: EAP-726.

Summary

• allocation_policy is a per-resource list of {match, policies, remove} blocks.
• Match keys (organization_id, project_id, referrer) are always lists; AND across keys, OR within a key; match: {} always matches.
• Matching blocks apply in file order: remove names, then add/replace policies by name.
• EAP routing and SNQL db_query pass request tenant_ids into get_active_allocation_policies.
• Drop unused required_tenant_types. Stop baking policies onto Table; attach at quota time from storage_key.

Testing

• SNUBA_SETTINGS=test uv run pytest -q tests/query/allocation_policies/test_attachment.py tests/web/test__get_allocation_policy.py

[linear-code]

EAP-726

[sentry]

Bug: The function _block_matches assumes match values are iterable. A scalar value (e.g., an integer) will cause an uncaught TypeError, crashing the request handler.
_{Severity: HIGH}

Suggested Fix

Add a type check in _block_matches to ensure the expected value from the match dictionary is a list or other iterable. If it's not, either wrap it in a list to handle the scalar case gracefully or log a warning and skip the invalid policy, similar to how other malformed configuration entries are handled.

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/__init__.py#L585-L586

Potential issue: The `_block_matches` function assumes that values for keys in the
`match` dictionary of an allocation policy are always iterable. However, if a policy is
misconfigured with a scalar value (e.g., `{"organization_id": 123}`) instead of a list
(`{"organization_id": [123]}`), the expression `tenant_ids[key] in expected` will raise
a `TypeError`. This exception is not caught within the call stack
(`_resolve_policy_specs` -> `get_active_allocation_policies` ->
`_get_allocation_policies`). Since `_get_allocation_policies` is called outside the main
`try/except` block in `db_query`, this error will crash the request handler for any
query using that resource until the configuration is corrected.

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

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit fa4a193. Configure here.}

[tryangul]

Nit: get_active_allocation_policies + its four helpers (_resolve_policy_specs, _block_matches, _apply_block, _construct_policies) are a self-contained unit. What if we put them in a class or even a module, e.g. allocation_policies/resolver.py,AllocationPolicyResolver ). This init is already pretty crowded. Non-blocking ofc.

[tryangul]

What's the downside in just passing the attribution_info around for maximal context?

[tryangul]

Logic seems good to me 🚢

Left a nit on adding some structure. I think it's worth exploring as a follow up, esp if we want to build on this thing / swap it out later.