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.}

[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.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

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

[sentry]

Bug: When a request omits the limit and limit_by fields, the logic fails to trim the extra sentinel row used for pagination, causing it to leak into the response.
_{Severity: MEDIUM}

Suggested Fix

Modify the logic that sets effective_limit. When in_msg.limit is 0 and limit_by is not set, effective_limit should be set to _DEFAULT_ROW_LIMIT. This will ensure the subsequent check correctly identifies that the result set needs to be trimmed by one row, preventing the sentinel row from being included in the final response.

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#L1160-L1161

Potential issue: When a request is made without an explicit `limit` and without a
`limit_by` clause, the logic to trim the extra sentinel row used for pagination fails.
The `effective_limit` variable remains 0, causing the condition `if effective_limit > 0
...` to be false. As a result, `islice` is never called to remove the extra row fetched
for pagination detection. This leads to the API returning up to `_DEFAULT_ROW_LIMIT + 1`
rows (e.g., 10,001) instead of the expected maximum of `_DEFAULT_ROW_LIMIT` (10,000).