ref(resolvers): inline the trace item table resolver

[MeredithAnya]

Stack

1. ref(resolvers): remove unused resolver declarations #8451 ref(resolvers): remove unused resolver declarations
2. ref(resolvers): inline the trace item stats resolver #8452 ref(resolvers): inline the trace item stats resolver
3. ref(resolvers): inline the time series resolver #8453 ref(resolvers): inline the time series resolver
4. → #this ref(resolvers): inline the trace item table resolver
5. ref(resolvers): remove the TraceItemDataResolver abstraction

What

Same transformation as #8452 and #8453, applied to EndpointTraceItemTable. ResolverTraceItemTableEAPItems was the last concrete resolver.

Moves the resolver module body into endpoint_trace_item_table.py and turns resolve() into _query_trace_item_table reading self.routing_decision.

This is the biggest of the three — the resolver was 897 lines, so endpoint_trace_item_table.py ends up around 1200. It's a pure move: nothing in the pasted body changed, so the added lines should diff cleanly against the deleted file.

After this, resolvers/__init__.py declares no resolver classes at all. The abstraction itself comes out in the next PR.

Tests

Import/patch-target updates only. pytest tests/web/rpc/v1/test_endpoint_trace_item_table/ test_storage_routing.py test_cross_item_local_join.py → 198 passed. mypy snuba/web/rpc/ clean.

🤖 Generated with Claude Code

[sentry]

Bug: The pagination logic at _get_page_token incorrectly compares num_rows_returned with request.limit (which can be 0), instead of the effective query limit, causing pagination to fail.
_{Severity: HIGH}

Suggested Fix

The pagination logic should use the effective limit applied to the database query, not the raw request.limit value. When request.limit is 0, the comparison should use the default row limit (e.g., _DEFAULT_ROW_LIMIT) to correctly determine if there are more pages.

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/web/rpc/v1/endpoint_trace_item_table.py#L799

Potential issue: When a flextime-routed query is made without an explicit `limit`, the
`request.limit` defaults to 0. The database query correctly uses a default limit (e.g.,
10,001 rows), but the pagination logic in `_get_page_token` compares the number of rows
returned against the original `request.limit` of 0. This `num_rows_returned > 0`
comparison will always be true if any data is returned, causing the system to
incorrectly issue a next-page token for the same time window. This prevents pagination
from advancing to subsequent time windows or ever finishing, leading to incomplete data
or infinite loops for the client.

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