fix(schema.json): policies can accept any number of arbitrary properties

[pbhandari]

Allocation policy items in sentry-options currently fail schema validation when they include constructor overrides beyond the few named fields.

Allow additional numeric properties on each policy object so per-policy default_config_overrides can be set without listing every config key in the schema.

Follow-up to #8393.
Linear: EAP-726.

Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

[sentry]

Bug: The schema allows number for additionalProperties, but the code strictly checks for int types, causing an unhandled ValueError if a float (e.g., 5.0) is used.
_{Severity: HIGH}

Suggested Fix

Change the JSON schema for additionalProperties from "type": "number" to "type": "integer". This ensures the values provided in the configuration match the strict type expectations of the Python code, preventing the unhandled ValueError.

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: sentry-options/schemas/snuba/schema.json#L380-L382

Potential issue: The JSON schema for `allocation_policies` allows `additionalProperties`
of type `number`, which includes both integers and floats. However, the `Configuration`
dataclass in the Python code performs a strict type check (`type(value) is
expected_type`). If a user provides a float value (e.g., `5.0`) for a configuration that
expects an `int`, a `ValueError` is raised during policy initialization. This exception
is not caught in `_construct_policies`, which will crash the policy resolution process
and impact resource allocation and query rate limiting.

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

[phacops]

This is a nice hack but that's OK. Ideally, we'd spec out correctly the additional properties.

[linear-code]

EAP-726