Fix slug rewriting for *.notion.site users

[shigahi]

Summary

• Server-side: Replace 302 redirect with direct fetch-and-serve for slug pages. Previously, visiting a slug URL (e.g., /a-propos) triggered a 302 redirect to /<pageId>, which allowed Notion's client-side app to overwrite the URL with username-prefixed paths (e.g., /philipb/Page-Title-<id>). Now the Worker internally rewrites the path and serves the page directly, keeping the browser URL at the clean slug.
• Client-side: Add a 2-second fallback timer for slug rewriting. The existing MutationObserver only triggers when .notion-topbar appears, but published *.notion.site pages may not have this element. The fallback ensures updateSlug() and the onpopstate handler are initialized even without the topbar.

Closes #55

Context

Reported by @Ph15 in #55 (comment). After the XHR domain fix (#62), the site loaded but slugs stopped working - URLs showed the full Notion path (e.g., vivrerelies.org/philipb/Vivre-reli-s-fe4785129e764baf85f54bb86cad7d1e) instead of clean slugs (e.g., vivrerelies.org/).

Test plan

• Verify slug pages load correctly for *.notion.site users (URL stays at slug, not page ID)
• Verify slug pages still work for www.notion.so users (backward compatibility)
• Verify in-app navigation between slug pages rewrites URLs correctly
• Verify browser back/forward maintains correct slug URLs
• Build succeeds (npm run build)