Release tracking schemas and storage layer landed
GitPulse now stores release data alongside stories. Every GitHub release gets its own validated JSON file with denormalized top stories and an inputsHash for skipping redundant AI calls.
GitPulse can now track GitHub releases as a first-class entity. This PR lays the groundwork: a data schema, file storage with write-time validation, and the plumbing to restore release data from a deployed site. The storage layout mirrors the existing stories pattern — a manifest index plus one file per release tag — so the site can render release detail pages without fetching every linked story.
A release aggregates all PRs merged between two tags. The top stories are denormalized directly into the release file, letting the site render the detail page in one read. Each release also carries an inputsHash field: if the analyzer produces the same hash on a subsequent run, the LLM call gets skipped entirely. Tags containing slashes (like release/v1.0.0) are URI-encoded in the filename while the canonical tag stays in the JSON.
This is Phase A of a three-phase effort. Phase B will wire in the GitHub API fetcher and LLM summarizer. Phase C adds the frontend. The foundation is solid: 40 action tests pass, typecheck is clean, and no site code was touched.