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>

lib/db.ts

@@ -1,11 +1,7 @@
 import Database from 'better-sqlite3';
 import path from 'path';
 
-// Next to the checkout by default, which is what every desktop instance wants.
-// `AUTOFIRMER_DB` moves it onto a mounted volume for the hosted dashboard, where
-// the working directory is inside a container image and is replaced on every
-// deploy — a database written there would be a fresh empty one each time.
-const db = new Database(process.env.AUTOFIRMER_DB || path.join(process.cwd(), 'autotrader.sqlite'));
+const db = new Database(path.join(process.cwd(), 'autotrader.sqlite'));
 
 db.pragma('foreign_keys = ON');