fix: news dates show a day early for viewers west of UTC

[sanity]

Problem

The homepage news list (rendered via the include-releases=true path of the latest-news shortcode) shows every article one day early for any viewer whose timezone is behind UTC (all of the Americas, and most of the site's likely audience).

Root cause: the server emits each static news item's date as midnight UTC (.Date.Format "2006-01-02T15:04:05Z"), and the client then formats it with toLocaleDateString in the viewer's own timezone. Midnight UTC converted to any negative-offset zone lands on the previous calendar day.

The plain (non-include-releases) path used by /about/news/ formats dates entirely server-side and is unaffected.

Approach

Format the date on the server, where the intended calendar day is known, instead of shipping a raw instant and re-interpreting it in an unknown client timezone (as the issue proposes):

• Add a dateDisplay field to the JSON news items, computed server-side via .Date.Format "January 2, 2006".
• In renderNews, prefer item.dateDisplay when present.
• GitHub release entries (fetched client-side and merged in) don't have a dateDisplay field and carry a real timestamp (published_at, not midnight), so they correctly fall back to the existing formatDate() client-side conversion.
• The raw date field is left untouched and still drives sort order.

I also checked for the same bug pattern (a server-emitted midnight-UTC instant reformatted with toLocaleDateString client-side) elsewhere in the repo. decentralized-services-issues.html and merged-pull-requests.html also call toLocaleDateString client-side, but on issue.created_at / pr.merged_at — real timestamps from the GitHub API with genuine time-of-day, not midnight-UTC-stamped dates — so timezone conversion there is legitimate and not the same bug. No other instances found.

Testing

• hugo --minify build succeeded; inspected the emitted data-news-items attribute on the built homepage and confirmed each entry now carries a correct dateDisplay (e.g. "date":"2026-07-24T00:00:00Z","dateDisplay":"July 24, 2026").
• Extracted the shortcode's exact renderNews/formatDate JS logic and ran it against the real built news-item JSON under TZ=UTC, TZ=America/Los_Angeles, and TZ=Pacific/Auckland. All three now render identical, correct calendar dates.
• Sanity-checked the test isn't vacuous: running the old logic (always formatDate(item.date)) against the same data under TZ=America/Los_Angeles reproduces the bug exactly — every date one day early (e.g. July 24 → July 23).
• Confirmed the plain /about/news/ path (lines untouched by this diff) still formats dates entirely server-side.

Closes #80

[AI-assisted - Claude]