Run SubstructLibrary queries concurrently within a GPU-memory budget

[scal444]

Instead of serializing every call, let queries run concurrently. Each finalize() works out how many queries fit below 85% of each GPU's memory, counting the batches it is about to replace as freed, and gives every GPU that many query slots, each a search workspace plus its match flags. A query takes one slot per GPU, and queries with recursive SMARTS also take one of a smaller number of slots for their scratch memory. maxConcurrentQueries() reports the limit.

Queries share the library lock; additions and finalize() take it exclusively, passing a gate first so queries that keep arriving cannot starve them. If a finalize() fails after resizing the slots, the previous slots are rebuilt.

The memory estimates live next to the search they describe, which also now resolves the default executors per runner in one place.

[greptile-apps]

Confidence Score: 5/5

[High risk] Adds concurrent query execution with GPU memory pooling.

The PR appears safe to merge, with no outstanding findings from this re-review.

Summary

The PR lets SubstructLibrary queries run concurrently within a GPU-memory budget.

• Adds per-GPU query slots and a separate limit for recursive queries.
• Keeps additions and finalize() exclusive and restores slots after a failed rebuild.
• Since the previous review, disables the test that incorrectly requires multiple slots on every GPU.
• The earlier reader-start and sequential-reuse concerns are addressed by readersReady and the corrected test description.

_{Reviews (4) · Last reviewed commit: "Disable memory-dependent query concurren..." · Reviewed by Greptile}

[scal444]

PR 4 for #350

[evasnow1992]

One clarification question. Changes look good to me.