Fix CSS cache-bust: use deployment_timestamp not request.timestamp

The static asset cache-buster in base.html was using
{{ request.timestamp|default:'1.0' }} — but `request.timestamp` is
not a Django request attribute, so the template always fell back to
the literal '1.0'. Every deploy's CSS URL resolved to the same
`custom.css?v=1.0`, so any CDN or browser cache in front of the app
held onto the pre-redesign CSS forever — even hard refreshes in
incognito couldn't bust it.

Symptom: after deploying the redesigned app, the browser continued
to receive a 1,734-byte pre-redesign custom.css while the VM's
/static/css/custom.css was the full 39,078-byte Premium Orange Theme.
.topbar-nav rules were missing, so the topbar rendered as stacked
block links.

Fix: use `deployment_timestamp` (already provided by
core.context_processors.project_context as int(time.time()) at
render time). Every restart gets a fresh URL, CDNs refetch from
origin, stale caches break.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

core/templates/base.html

@@ -25,7 +25,12 @@
     <!-- Font Awesome 6 -->
     <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.5.1/css/all.min.css">
     <!-- Custom CSS (cache-busted with deployment timestamp) -->
-    <link rel="stylesheet" href="{% static 'css/custom.css' %}?v={{ request.timestamp|default:'1.0' }}">
+    {# `deployment_timestamp` is provided by core.context_processors.project_context —
+       it's injected into every template so the browser (and any CDN in front of
+       the app) sees a fresh URL whenever the process restarts. The old template
+       used `request.timestamp` which doesn't exist on Django request objects and
+       always fell back to a fixed '1.0' — meaning CDNs cached the CSS forever. #}
+    <link rel="stylesheet" href="{% static 'css/custom.css' %}?v={{ deployment_timestamp|default:'1' }}">
 
     {% block extra_css %}{% endblock %}
 </head>