Add daily .zip docs release workflow

[PratikP1]

Summary

• Adds a GitHub Actions workflow that creates daily zip releases of docs/ (Markdown) and html/docs/ (HTML)
• Runs on a daily schedule (6:00 AM UTC) with manual dispatch support for the initial run
• Detects changes before creating releases — skips if no docs content has changed
• Names zip files as Git-Going-With-Git-yyyy-mm-dd.zip with release tags vyyyy-mm-dd
• Marks each release as latest and retains only the 10 most recent releases

Test plan

• Trigger workflow manually via workflow_dispatch to verify first run
• Confirm zip contains both docs/ and html/docs/ folders
• Verify release tag format (vyyyy-mm-dd) and latest tag assignment
• Confirm no release is created when docs content is unchanged
• Verify old releases beyond 10 are cleaned up

[Copilot]

Pull request overview

Adds an automated GitHub Actions workflow to publish daily GitHub Releases containing zipped docs/ (Markdown) and html/docs/ (HTML), with a manual trigger for the first run and cleanup of older releases.

Changes:

• Introduces a scheduled + manual GitHub Actions workflow to package docs into a date-stamped zip and publish a GitHub Release.
• Skips release creation when no docs changes are detected.
• Deletes same-day releases before recreating them and prunes old releases beyond the most recent 10.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[accesswatch]

Thanks for putting this together Pratik! A few questions before we move forward:

1. Trigger strategy: Would triggering on push to main be better than a daily cron schedule? That way releases only happen when content actually changes, and you wouldn't need the change-detection logic. The daily schedule creates workflow runs even when nothing has changed.

2. Naming: The zip is named 'Git-Going-With-Git' but the repo is 'git-going-with-github' - should the zip name match the project name?

3. Retention: Is 10 retained releases enough? For a documentation project, participants may reference older versions from past workshops. Consider bumping to 20-30 or making it configurable.

4. Next revision timing: We are working on a significant documentation update. It might make sense to hold off merging this until that revision lands so the first release contains the updated content.

Happy to revisit once we sort these out.