fix: prevent XSS in markdown rendering and ATOM feed

[mattwoberts]

Summary

Fixes GHSA-wm2w-gfh7-qg69 — Unsafe Markdown Rendering Leading to Potential XSS.

• Re-enable HTML entity encoding in public/services/markdown.ts — was disabled during Tiptap editor integration (commit ac36ede), but the Tiptap editor outputs markdown (configured with html: false), not HTML, so encoding </> before marked processes input is safe and necessary
• Remove html.UnescapeString() in app/handlers/feed.go — comment content is stored as-is in the DB, so unescaping before markdown rendering needlessly converts HTML entities back to raw HTML in ATOM feed output
• Harden SSR fallback — when DOMPurify.isSupported is false (SSR/older browsers), strip HTML tags instead of returning raw unsanitized input
• Add XSS prevention tests — frontend tests for <script>, <img onerror>, <svg onload>, javascript: URIs; backend test verifying <script> tags are escaped in ATOM feed output

Test plan

• Create post/comment with <script>alert(1)</script> — verify it renders as escaped text
• Create comment with <img src=x onerror=alert(1)> — verify no JS executes
• Check /feed/global.atom and /feed/posts/{n}.atom — verify no unescaped HTML
• Verify Tiptap editor still works: bold, italic, links, code blocks, mentions, image upload
• Toggle between rich text and markdown mode — verify content survives round-trip
• Run make lint and make test

[PratikKaran23]

Thanks for the quick fix. The pre-encoding approach before marked is solid, one suggestion: consider adding a backend test for javascript: URIs in comments to mirror the frontend coverage in feed_test.go.