Subscribable webcal:// feed for cohort sessions

[unforced]

Context

Shipped in https://github.com/Unforced-Dev/learnvibe.build/pull/... — /cohort/:slug/sessions.ics currently serves a one-time download. If the meeting URL changes, or a session is rescheduled, every attendee needs to re-download and re-import.

A subscribable feed (served at webcal://learnvibe.build/cohort/cohort-1/sessions.ics) would let calendar clients poll and auto-update.

Proposal

The ICS bytes we already generate are fine as a subscribable feed — this is mostly a UX change:

1. Add a second CTA on the banner — "Subscribe (auto-updates)" next to "Download (.ics)". The subscribe link uses webcal:// and the download link uses https://.
2. Per-client quick links: some calendars don't handle webcal:// well from a button. Consider adding a dropdown with:
   • Google Calendar: https://calendar.google.com/calendar/r?cid=https%3A%2F%2Flearnvibe.build%2Fcohort%2Fcohort-1%2Fsessions.ics
   • Apple Calendar: webcal://learnvibe.build/cohort/cohort-1/sessions.ics
   • Outlook: the subscribe URL, with instructions
3. Cache headers: currently no-store. For a subscribed feed, something like Cache-Control: public, max-age=900 is friendlier (clients poll roughly hourly; 15min serves changes fast without hammering).
4. Stable UIDs: events already have stable UIDs keyed on slug + week. Adding a SEQUENCE field that increments when the event changes (e.g. when meeting URL updates) would help clients treat updates as updates rather than new events.

Implementation notes

• Requires the schedule-fields issue (Move session schedule from hardcoded ICS to cohorts table fields #15) to land first if we want mid-cohort schedule changes to propagate cleanly.
• Consider auth: today the endpoint checks canAccessCohort. That gate only works in-browser (cookie-based). Calendar clients won't carry the cookie when polling. Options: (a) make the feed public (meeting URL is a secret, so probably not), (b) sign the URL with a per-user token, (c) expose a Clerk-authenticated ICS only via a personalized path like /my/calendar/:token.ics.
• (c) is the cleanest long-term answer and probably the right shape for this issue's scope.

Out of scope

Native "Add to Google Calendar" deep-links that pre-fill a single event (already covered by the download flow for the common case).