assets:migrate must not require a .env file

It read the repo-root .env with a bare readFileSync and died on ENOENT
where there wasn't one — which is every container, including the server
this deploys to. Migrations and the seed both ran fine on the Dokploy
host; this was the only step of the deployment that could not.

The loop already used `??=`, so a variable present in the environment
always won and the file was never the authority. Its absence is now the
ordinary case it always should have been.

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

packages/db/src/migrate-assets.ts

@@ -26,9 +26,21 @@ import {
 import * as schema from './schema/index';
 import { readSsl } from './client';
 
-for (const line of readFileSync(new URL('../../../.env', import.meta.url), 'utf8').split('\n')) {
+/*
-  const m = /^([A-Z_]+)=(.*)$/.exec(line.trim());
+ * The repo-root .env, when there is one.
-  if (m?.[1]) process.env[m[1]] ??= m[2];
+ *
+ * `??=` means a variable already in the environment always wins, which is what
+ * makes this safe to skip: in a container there is no .env and the platform
+ * supplies everything directly. Insisting on the file turned this script into
+ * the one step of a deployment that could not run on the server it deploys to.
+ */
+try {
+  for (const line of readFileSync(new URL('../../../.env', import.meta.url), 'utf8').split('\n')) {
+    const m = /^([A-Z_]+)=(.*)$/.exec(line.trim());
+    if (m?.[1]) process.env[m[1]] ??= m[2];
+  }
+} catch {
+  // No .env — expected anywhere the environment is injected rather than filed.
 }
 
 const url = process.env.DATABASE_URL;