feat(blog): add revision history and rollback workflow for blog posts

[RsbhThakur]

Closes #32.

Follows up on #28 and #39 to implement a complete Blog Revision History system. Published posts now maintain an immutable, chronological snapshot history of every version across direct admin edits, approved member revisions, and rollbacks. Both administrators and member authors can inspect visual diffs against live content or previous versions, and restore historical snapshots with strict RBAC guarantees.

---

Key Changes

1. Data Model & Storage Strategy

• Dedicated Collection (BlogPostRevision):
  • Revisions are persisted in a separate BlogPostRevision collection rather than an unbounded subdocument array on BlogPost, preventing document bloat, fragmentation, and the 16MB BSON limit.
  • Stores full immutable snapshots: postId, slug, version, title, content, excerpt, coverImage, coverFocalPoint, tags, authors, editor, approvedBy, source ("initial_publish" | "admin_edit" | "approved_revision" | "rollback"), restoredFromVersion, changeSummary, and createdAt.
  • Compound unique index { postId: 1, version: -1 } guarantees atomic version sequences, with secondary indexes on { slug: 1, createdAt: -1 }.
• Zero-Migration Backwards Compatibility:
  • recordRevisionSnapshot automatically synthesizes and seeds a Version 1 baseline snapshot for legacy published posts on their next edit, ensuring seamless upgrades with zero downtime or database backfills.

2. Mutation Integration & Snapshot Capture

• Publication Lifecycle:
  • POST /api/admin/blog: Automatically records Version 1 when a post is created directly as published.
  • PATCH /api/admin/blog/[slug]: Records Version 1 when transitioning a draft to published, or increments the version snapshot on direct admin content changes.
  • POST /api/admin/blog/[slug]/revision: Records a version snapshot upon admin approval of a member edit, attributing the author as editor and the approving admin as approvedBy.
  • DELETE /api/admin/blog/[slug]: Cascades deletion to remove all associated historical snapshots when a post is permanently deleted.

3. API Endpoints & Role-Based Restores

• Admin Revision Routes (/api/admin/blog/[slug]/revisions):
  • GET: Lists version summaries (omits heavy Markdown bodies) or retrieves a specific version's full content.
  • POST /api/admin/blog/[slug]/revisions/[version]/restore: Reverts the live post directly to an earlier snapshot, records a "rollback" snapshot in history, writes a fail-closed audit log, and invalidates the edge cache.
• Member Author Revision Routes (/api/internal/blog/[slug]/revisions):
  • GET: Lists version summaries for posts authored by the requesting user (isBlogAuthor).
  • POST /api/internal/blog/[slug]/revisions/[version]/restore: Restores historical content into the staged draft (pendingRevision) without modifying live content, strictly preserving the review and approval safeguards introduced in PR feat(blog): allow members to edit published posts with approval workflow #39.

4. UI & Visual Diffing

• Editor Toolbar Integration (BlogEditorToolbar):
  • Added a "Revision history" clock icon button next to the preview and save controls, active in both /admin/blog/[slug]/edit and /internal/blog/[slug]/edit.
• Interactive Revision History Modal (RevisionHistoryModal):
  • Two-pane layout: Left pane renders a chronological timeline with version badges, relative timestamps, author/approver badges, and commit notes.
  • Multi-mode diff inspector: Compare selected version with Live (live), with Previous (vN-1), or view raw markdown.
  • Contextual restore actions: Tailored confirmation modals for admins ("Revert Live Post") and authors ("Load into Staged Draft").

[maydayv7]

1. Always check permissions and other state within the API call (in src/app/api/internal/blog/[slug]/revisions/[version]/restore/route.ts) like so to prevent race conditions and ensure security. I've also mentioned this in your previous PR.
2. Unpublishing and republishing loses history?
3. Restore overwrites drafts awaiting review.

[RsbhThakur]

Thanks for the review @maydayv7! Fixed all three points:

1. Permission check: Moved the user and permission checks directly inside the database transaction so there's no risk of race conditions or state changes slipping through.
2. Unpublish / republish history: Fixed this so taking a post down and republishing it keeps the full revision history intact instead of wiping the past versions.
3. Protected pending reviews: Restoring an old version is now blocked if an author currently has changes submitted and waiting for admin review, so unreviewed work won't get accidentally overwritten.

Also added tests covering all three cases. Let me know if everything looks good to merge!