Actually fix WNS push, and stop the notification toggle hanging forever (#56)

The pywebpush version bump alone didn't fix WNS: even the latest
release (2.4.0) has no WNS-specific header handling in its own
source, confirmed by inspecting the installed package directly.
Adds the required X-WNS-Cache-Policy header ourselves via
webpush()'s own headers= param, gated to *.notify.windows.com
endpoints.

Also: subscribeToPush()'s permission request and service-worker-ready
wait had no timeout, so a browser that never settles either (seen
live on a fresh Windows/Edge install -- greyed out, no prompt, no
error) left the toggle stuck forever with no feedback. Both now time
out after 20s with an actionable message instead.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

backend/pyproject.toml

@@ -15,13 +15,13 @@ dependencies = [
     "pydantic-settings>=2.6",
     "argon2-cffi>=23.1",
     "itsdangerous>=2.2",
-    # #56: >=2.0 let the production venv sit on an old 2.0.x that predates
-    # the fix for web-push-libs/pywebpush#162 -- WNS (Windows/Edge push)
-    # has required an X-WNS-Cache-Policy header since April 2024, and an
-    # old pywebpush that never sends it gets a bodyless 400 on every send.
-    # Floored at the actual latest release (merged/shipped 2026-01 through
-    # 2026-08) rather than pinning to whichever exact point release first
-    # included the fix, since that wasn't independently confirmed.
+    # #56: >=2.0 let the production venv sit on an old 2.0.x with no real
+    # downside to bumping the floor -- worth keeping current regardless.
+    # Doesn't by itself fix WNS (Windows/Edge push): despite
+    # web-push-libs/pywebpush#162's discussion, even the latest release
+    # (2.4.0) has no WNS-specific header handling in its own source. The
+    # actual fix is app/services/push_service.py adding the required
+    # X-WNS-Cache-Policy header itself via webpush()'s `headers` param.
     "pywebpush>=2.4.0",
     "redis>=5.0",
     "httpx>=0.27",