Handle Grain API rate limiting in the daily meeting fetch

[dplakon]

Problem

Today's grainiac-orchestrator run could not get off the ground: scripts/fetch_daily_meetings.py today failed with HTTP Error 429: Too Many Requests on every attempt, before returning a single meeting.

Two independent causes:

1. No retry or backoff. _get raised on the first 429, aborting the whole run.
2. Unbounded pagination. list_all_recordings walked the entire recording history (up to 100 pages × 20 recordings) on every run, even though the caller only wanted one day. The Grain API advertises a budget of 30 requests per window (x-ratelimit-limit: 30), so the fetch reliably exhausted its quota partway through pagination — it consistently died on page 2 of a fresh run because prior runs had already drained the window.

The API's afterDatetime / beforeDatetime parameters do not filter server-side (confirmed: a request scoped to 2026-07-30 still returned recordings from 2026-07-27), which matches the existing note in the orchestrator skill. But results are returned newest-first, so a single-day fetch never needs to read past the target date.

Changes

scripts/grain_client.py

• New _request helper with exponential backoff on 429 and 5xx, honouring Retry-After when present.
• Proactive throttle: pause when x-ratelimit-remaining drops to the threshold, rather than waiting to be rejected.
• get_transcript_text now shares the same retry path (it previously had its own un-retried request).
• list_all_recordings accepts stop_before_date and stops paging once an entire page predates the target day.

scripts/fetch_daily_meetings.py

• Passes the resolved target date as stop_before_date.

Result

A single-day fetch now costs 2 list requests instead of up to 100. Verified end to end against the live API — the run that previously failed now completes:

Resolved 'today' to 2026-07-30 (timezone: America/Los_Angeles)
Fetched 40 total recordings
Found 4 recordings on 2026-07-30
Found 4 external customer meetings

Follow-ups for a human (not fixed here — these are config, not code)

• GRAINIAC_NOTION_DATABASE_ID is stale. The configured ID (3a043263616d803d98de000c5b916204) returns 404 from the Notion API. The database the pipeline actually writes to is "Account Management" (3a043263-616d-80bd-a6da-f099fa90796a), which holds all 44 account pages and follows the Grainiac page template. The env var should be repointed.
• GRAINIAC_NOTION_TITLE_PROPERTY is unset. That database's title property is Account name, but notion_client._title_property() defaults to Company, so find_company_page would filter on a non-existent property. The var needs to be set to Account name.

Conversation: https://app.warp.dev/conversation/0c3b3ac6-8718-4b83-990b-d450a1868f9a

Run: https://oz.warp.dev/runs/019fb68b-2f46-73e6-b14c-ca2dc1614964

This PR was generated with Oz.