Database constructor performs unwanted blocking / erroring operations

Running new Database with a configuration that wants to use a remote sqld will cause the program to block on disk or network I/O for some amount of time, potentially for very long amounts of time. It can also cause the constructor to fail. There are two problems with this off the top of my head:

• It's highly unexpected for a constructor to block in JS, especially for setups that want to eagerly create objects for later use, or expect that their DI never blocks or fails, and always provides an object.
• It prevents the program from working at all if something is wrong establishing a connection to the server at the time the constructor is called (unless the requirement is that the caller should catch and retry errors with the constructor, which I don't like).

It would be more clean if the constructor only failed on configuration or programming errors (or I suppose whatever might make the underlying better-sqlite3 constructor fail, but it might be reasonable to delay that as well). This would allow the program to work if initially offline or without connection, and make error recovery easier to implement. As an alternative:

• The request to pull new data could lazily contact the server and yield an error message at that point.
• The SDK could eagerly contact the server off the main thread so that it's quickly ready for the first sync.

Start at the Database constructor and trace how a remote sqld configuration reaches disk or network operations. Reproduce construction while offline, then verify that temporary connection failures are deferred while configuration or programming errors still fail as intended.