fix(eap): Keep EAP queries inside the full-fidelity retention window

[phacops]

Snuba is about to make long-term-retention downsampling unconditional
(snuba#8235): any EAP query whose window
starts more than 31 days ago is routed to the TIER_8 downsampled table, unless the item
type is in ITEM_TYPE_FULL_RETENTION. EAP endpoints default to a 90 day window when a request
omits statsPeriod/start/end, which is past that boundary.

• full_retention_window() now anchors to tier 1's 30 day retention. The 90 day default could
  never surface older data anyway; it just guaranteed these context existence checks ran against
  a sampled tier and could report an existing attribute as absent.
• Tests get the same window by default via apply_eap_default_stats_period(), wired into the
  shared request helpers. Fixtures only land in the tier 1 table, so a downsampled query sees an
  arbitrary ~1-in-8 subset of what the test just stored. A few tests that stored 35–80 day old
  data were moved inside the window.

Note that HIGHEST_ACCURACY does not rescue these queries: in _update_routing_decision the
TIER_8 assignment happens above the highest-accuracy early-return, so the window itself has
to stay inside the boundary.

The 30 day window leaves as little as a second of headroom, since adjust_start_end_window()
floors the start to midnight and Snuba evaluates the boundary at query time. That margin is
accepted deliberately to keep the full 30 days.

Datasets are derived from RPC_DATASETS rather than hardcoded so the set can't drift, minus
uptime_results/preprodSize to mirror Snuba's ITEM_TYPE_FULL_RETENTION.

I could not run the affected Snuba integration tests locally (no image pull for the Snuba
container), so the reasoning comes from the routing source plus confirming the materialized view
predicate against live ClickHouse, not a green run — worth watching CI here.
_trace_connected_issues_eap in sentry/issues/related/trace_connected.py has the same shape
and will also be downsampled; left out to keep this scoped.

[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 1726a0b. Configure here.}

[k-fish]

Reading this, just to clarify; since all base trace item types (spans / logs / metrics) are 30d full (+ optional 13 month downsampled), we're just matching the hardcoded values on the retention_days with the query window?

Actual nit; Isn't the downsampling stable? Can't we just mock eap items that match the hash + modulo (and ones that don't) so we can actually test the downsampling is working / being applied as expected?