feat(fred): get_revisions and get_release_calendar

[walkerhughes]

Closes #34. Fourth of the fred stack (#30), on top of #38. Last PR with code in it.

Two tools for questions the raw API makes genuinely hard, not just verbose.

get_revisions

FRED is also ALFRED: it keeps every vintage of every number. "What did Q3 GDP originally print at, before the revisions?" is a real question, and answering it by hand means knowing that output_type=4 means initial-release-only and that it silently fails unless you also widen the real-time window:

$ curl '.../series/observations?series_id=GDPC1&output_type=4&observation_start=2025-07-01'
{"error_code":400,"error_message":"Bad Request.  No vintage dates exist for the
 specified real-time period: 2026-08-05 to 2026-08-05."}

That message reads like the series has no revision history. It actually means a parameter is missing. The tool sets realtime_start=1776-07-04&realtime_end=9999-12-31 itself, and that single detail is most of its value.

With observation_date, it collapses the vintages. output_type=2 returns one column per vintage, but a vintage exists for every publication of the series, not for every change to this observation, so most columns repeat the one before. Live, Q3 2025 GDP has nine vintages and one actual revision:

Q3-2025 GDP: 1 revision
  {vintage: 2025-12-23, value: 24024.957}
  {vintage: 2026-01-22, value: 24026.834, change: 1.877, pct_change: 0.0078}

Without one, first-printed against current across recent observations, which shows the revision pattern at a glance:

{date: 2025-10-01, initial: 24111.83,  current: 24055.749, revision: -56.081, revision_pct: -0.2326}
{date: 2026-01-01, initial: 24174.527, current: 24180.419, revision:   5.892, revision_pct:  0.0244}
{date: 2026-04-01, initial: 24270.599, current: 24270.599, revision:   0.0}
revised 4 of 5 | vintages {count: 417, latest: 2026-07-30}

get_release_calendar

What just came out, and what is next. Split around today, because those are two questions and comparing dates to tell them apart is work the caller should not do.

The bug worth reading about

The first version issued one request for the whole window and split the results locally. Live, that returned:

window 2026-07-29 to 2026-08-19 | released 50, upcoming 0

There were 385 scheduled releases in that window. limit truncates before the split, and FRED returns dates ascending, so the truncation lands entirely on the future. The tool confidently answered "nothing is coming up" to the half of the question it exists for.

Each half is now its own request with its own limit, and each reports FRED's own total so a limited page is visibly a page:

window 2026-07-29 to 2026-08-19 | totals {released: 231, upcoming: 385}
  released: 2026-07-29 CBOE Market Statistics, ...
  upcoming: 2026-08-06 Bankrate Monitor, ...

A purely historical window still costs one request, not two, and does not set include_release_dates_with_no_data (without which FRED returns only dates that already produced data, which is the other way this tool can silently answer "nothing").

release_id narrows to one publication and names it, which closes the discovery loop: get_release_calendar gives you release 50, search_series(release_id=50) lists every series it publishes.

release 50: Employment Situation | next: 2026-08-07, 2026-09-04, 2026-10-02

Verification

280 tests, 98% coverage, make check clean. Integration tests pin the clock to the fixture's TODAY, so the released/upcoming split is deterministic rather than passing until the fixture ages out.

The mock reproduces FRED's real-time-window failure, so the test asserting the window is set fails loudly if that parameter is ever dropped.