RSS feed for Forkcast

I'd like Forkcast to have an RSS feed. My use case is I recently launched Ethernews (ethernews.org), an Ethereum news aggregator, and I want Forkcast as a primary source there which needs a feed. An RSS feed also helps anyone else following upgrades from a reader.

Thinking on design after reviewing the code

Forkcast publishes three kinds of content that could be feed items:
1. Call summaries (tl;dr and key decisions per ACD call) - the highest news value, but also the content that syncs in from ACDbot via cron without a review step on the Forkcast side
2. EIP stage changes (already exposed at /api/eip-stage-changes.json)
3. Protocol upgrade status changes

Design constraint I heard from @wolovim: control over when feed items generate and what they include, since automated syncs deploy on their own schedule.

Proposal:
- A static feed.xml generated at build time, modeled on the existing eip-stage-changes.json.ts endpoint
- One feed with each content type behind a switch in a small hand-edited data file that only humans commit. Bot-synced LLM content can never enter the feed without a human sign-off.
- Call summary items additionally gated on a per-call reviewed marker in that same file.
- Deterministic GUIDs (e.g. {eip}-{stage}-{date}) so the multiple daily bot-triggered rebuilds never re-date existing items

v1 could ship with EIP stage changes enabled (lowest risk, data already public) and call summaries built but switched off until the review flow feels right.

Open questions:

1. Which types to enable at launch?
2. Gate: per-item allowlist, or per-type switches plus a reviewed flag for calls?
3. Hand-rolled XML matching the existing endpoint's style (no new dependencies), or @astrojs/rss?
4. Items as title plus link only, or with descriptions?

Happy to open a PR that includes a vitest test and rel=alternate once these are settled.

Start by reading the existing eip-stage-changes.json.ts endpoint and review how a static feed.xml could use its data. Settle the launch content, gating, XML or @astrojs/rss approach, and item descriptions, then add the mentioned vitest test and rel=alternate link; done means the feed is deterministic and only approved items are included.

Written by the indexing model from the issue text.