One connection, and settings that came as text

[tamnd]

This is the last of the C ABI that was not bound from the JVM, and none of it is a new thing the engine can do. It is the same calls with less to write around them.

try (Connection conn = Connection.open("social.zu1")) {
    ...
}

Config config = Config.of(Map.of("threads", "1", "memory_limit", "1073741824"));

A database and a connection are two objects because they are two things: the path and the configuration on one side, the caches and the plan cache and the file handle on the other, and a program querying from four threads wants one of the first and four of the second. A program that wants exactly one should not have to say so twice, so Connection.open, Connection.create and Connection.memory make the database inside the call and let go of it. Nothing is lost by that, since a connection carries its own file handle and a database holds only the path. What is given up is the second connection, and duplicate() is the way back to one.

Settings usually arrive as text, out of a properties file or a connection string or a command line, and a program holding a key and a value has no business knowing which of three fields they land in. Config.with(key, value) takes one by name and Config.of(map) takes a whole map, and both forward to zu_config_set rather than matching the key here, so a key the engine grows later works without a release of this client and a key that never existed is refused with the typo named.

Twelve tests. The one worth pointing at is that 512MB is refused rather than read as a number: the two readings of that suffix differ by 4.9%, and the place to decide which one somebody meant is where they typed it.

Local gate green: 183 tests, no failures.