Lifecycle: results and records keep their Database and raise once it is closed; failed create_vertices rolls back; set reads back as a list (#117, #121, #122)

[tae898]

Fixes #121, #122, and #117. The engine halves are filed upstream: ArcadeData#9038 (BinarySerializer swallowing DatabaseIsClosedException, for #117) and ArcadeData#9040 (GraphBatch.createVertices rolling back only for a NeedRetryException, for #121).

#121. GraphBatch.create_vertices opens its transaction inside the engine and the engine rolls it back only for a retryable error, so a duplicate key (or a KeyboardInterrupt) left it active and a later write outside any transaction was accepted and lost at close. The wrapper now rolls back, as create_vertex does after ArcadeData#8828, when the call started the transaction, and leaves one the caller already had open alone. Three tests: JSON-bulk and property-matrix paths, the caller's own transaction, and a KeyboardInterrupt after the engine's transaction began.

#117. ResultSet, Result, and the record wrappers now hold the Database that produced them and check it on every read, so a read after close() raises ArcadeDBError("Database is closed") as db.query does, instead of returning {} or None or a raw TransactionException. Holding the reference also keeps the database open while a result is alive, which is what stops Database.__del__ from closing it under a returned result. A result set read to its end still reads as empty. The consequence is documented and tested: while a result is alive the engine refuses a second open_database() of the same path ("already in use"), and with every result and record gone the wrapper's __del__ closes the database and the path opens again. Only a row that is a record (SELECT FROM T) needs the open database, so a projection or command Result that was already returned keeps its own values and stays readable after close(), and an unread result set raises. My first version refused every Result; the examples job caught that: example 16 reads the IMPORT DATABASE result after closing its database (macOS, and Linux with Python 3.14), which is fixed in the last commit and covered by a test.

#122. The conversion page said a set reads back as a set. That holds only inside the transaction that set it: the engine has no set type, so the HashSet is serialized as a list at commit. The tables, examples, and collection section are corrected, and a test pins the behavior so it fails if the engine ever keeps sets.

Verified: the new tests fail on origin/main (4 of 6 new tests for #117, 3 of 4 for #121; the rest are guards against regressing the other way) and pass with the change, the full suite passes (521 passed, 3 skipped, 3 xfailed), example 16 passes at its CI arguments, and bandit is clean at CI strictness.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DeKEhHXJTy1H1GgbfBZ8mL