feat(eap): Read TraceItemAttributeNames exclusively from co-occurring v2

[phacops]

EndpointTraceItemAttributeNames always reads eap_item_co_occurring_attrs_v2. Follow-up to #8239 / #7801.

Drops:

• use_co_occurring_attrs_v2 and co_occurring_attrs_v2_start_timestamp
• selection.py (flag + Monday date-window fallback to v1)
• last_seen → count degrade and attribute_names_order_by_degraded

v1 storage and MV stay populated; they are no longer queried.

Risk: v2 was created 2026-07-29 with no backfill. Requests whose weekly date bucket is before 2026-07-27 will miss keys that only exist on v1.

Verified: 175 tests in test_endpoint_trace_item_attribute_names.py, _v2.py, and the source contract suite.

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: Queries for co-occurring attributes before 2026-07-29 will return incomplete data because the fallback to the v1 table was removed, and the v2 table was not backfilled.
_{Severity: CRITICAL}

Suggested Fix

Reinstate the date-gated fallback logic. Queries with a start date before the co_occurring_attrs_v2_start_timestamp should be directed to the v1 table to ensure historical data remains accessible. Alternatively, perform a one-time backfill of the v2 table with data from the v1 table.

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_attribute_names.py#L241-L247

Potential issue: The code removes the fallback logic that queries an older `v1` table
for historical data. It now exclusively queries a `v2` table
(`eap_item_co_occurring_attrs_v2`) which was created on 2026-07-29 and was not
backfilled. As a result, any query for co-occurring attribute names with a date range
before this creation date will target a table that has no data for that period. This
will cause the endpoint to silently return empty or incomplete results for historical
queries, even though the data exists in the now-inaccessible `v1` table.

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