Address the file lock conflict on the DuckDB database that is incompatible with zero-downtime deployment methods where old and new application instances run concurrently.
**Summary:** I'm encountering a deployment issue when using a standard zero-downtime (or rolling update) deployment strategy with Medama. The core of the problem is a file lock conflict on the DuckDB database, which seems fundamentally incompatible with deployment methods where old and new application instances run concurrently for a short period. **The Core Problem:** Most modern deployment platforms (like Kubernetes, Dokku, Heroku, etc.) use a rolling update strategy to achieve zero-downtime: 1. A new application container/instance is started. 2. The platform waits for the new instance to become "healthy" (e.g., pass a health check). 3. Once the new instance is healthy, traffic is switched to it. 4. The old application instance is terminated. The issue occurs in step 2. While the old instance is still running and holding a lock on the database file, the new instance starts up and immediately tries to acquire a lock on the same `me_analytics.db` file located on a persistent v