Ship the extension as a signed CRX from our own update server

The dashboard-hosting stack from the previous commit is gone; it was answering
a question nobody asked. What was actually needed is Chrome's real update
channel, which an unpacked extension does not have and cannot be given.

So the extension is now signed into a CRX with an update manifest beside it,
served from the droplet, and installed on the trading machines by policy
(ExtensionInstallForcelist). From there Chrome installs it, updates it on its
own schedule, and puts it back if it goes missing. The manifest gained the
`key` that fixes the extension id, so an unpacked development load keeps the
same identity as the published build.

The self-update check now branches on how it was installed: policy installs ask
Chrome to check the update server now rather than waiting out its five-hour
cycle, and unpacked loads keep the reload-from-disk path. chrome.management
.getSelf() tells the two apart and needs no permission to do it.

The signing key lives at /opt/autofirmer-updates/key.pem on the droplet and
nowhere else. It is the extension's identity: a different key is a different
extension, and no browser would take it as an update.

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

deploy/nginx/updates-static.conf

@@ -0,0 +1,25 @@
+# Inside the little file-server container. Not the public-facing config — that
+# is ext.conf.template, rendered into the shared nginx.
+server {
+    listen 80;
+    root /srv;
+
+    # Replaces the whole MIME table, which is fine when the whole site is two
+    # files. Chrome is happy to take a CRX as octet-stream, but the updater logs
+    # are much easier to read when the type is right.
+    types {
+        application/x-chrome-extension crx;
+        text/xml                       xml;
+    }
+    default_type application/octet-stream;
+
+    # The update manifest is the thing Chrome polls to notice a release; a cached
+    # copy is a release that does not land. The CRX itself is named by version
+    # inside that manifest, so caching it would be safe — but it is one small
+    # file fetched once per update, and a single rule is easier to trust.
+    add_header Cache-Control "no-store" always;
+
+    location / {
+        autoindex off;
+    }
+}