Fix silent login failure on infra without HTTPS yet, and build-time SQLITE_BUSY

Session cookie always set Secure (tied to NODE_ENV=production, hardcoded in
the Dockerfile), which the browser silently drops over plain HTTP — looked
like login accepted the password but bounced straight back to /login. Secure
now only drops when COOKIE_ALLOW_INSECURE=true, for temporary use before the
HTTPS reverse proxy is wired up.

Also fixed pragma order in db/client.ts: busy_timeout must be set before
journal_mode, since switching to WAL itself takes a momentary exclusive lock
that isn't covered by a busy_timeout set afterward — caused an intermittent
SQLITE_BUSY during `next build`'s parallel page-data collection.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012o9j9RezxbZVKQMrB7oRLY

src/lib/db/client.ts

@@ -8,14 +8,13 @@ const dataDir = process.env.DATA_DIR ?? path.join(process.cwd(), "data");
 fs.mkdirSync(dataDir, { recursive: true });
 
 const sqlite = new Database(path.join(dataDir, "db.sqlite"));
+// busy_timeout MUST be set before journal_mode: switching to WAL itself
+// takes a momentary exclusive lock, and if a concurrent worker is mid-switch
+// on a fresh db.sqlite, that first statement has no busy_timeout protection
+// yet and throws SQLITE_BUSY immediately instead of waiting.
+sqlite.pragma("busy_timeout = 30000");
 sqlite.pragma("journal_mode = WAL");
 sqlite.pragma("foreign_keys = ON");
-// Next's build-time page-data collection evaluates route modules across
-// several worker processes concurrently — without this, two workers
-// racing to open/initialize a fresh db.sqlite can throw SQLITE_BUSY
-// instead of just waiting for the other's lock to clear. 5s wasn't enough
-// once the route count grew — bumped to 30s (build-time only cost).
-sqlite.pragma("busy_timeout = 30000");
 
 export const db = drizzle(sqlite, { schema });
 export type DB = typeof db;