feat(pipeline-void)!: iterate property partitions per property

[ddeboer]

entity-properties.rq computes COUNT(DISTINCT ?s) and COUNT(DISTINCT ?o) grouped over every property in a single query. On large datasets that materializes the full scan: measured on RKD’s 608M-triple dump (dataset-knowledge-graph), the query exhausts a 12 GB and a 16 GB QLever memory-max-size budget (‘Tried to allocate 24 B, but only 0 B were available’), so the dataset ends up with no property partitions and – because vocabulary detection derives from the void:property output – no void:vocabulary either. Raising memory further is not an option: the need scales linearly with dataset size, and the 86 per-class stages on the same dataset all pass because they are already chunked.

This applies the existing per-class chunking pattern to the property-partition stage:

• propertySelector() shares a distinctItemSelector helper with classSelector(): a cheap SELECT DISTINCT (now with ORDER BY, so LIMIT/OFFSET pagination is stable) feeds batches that the reader injects as a VALUES block into the innermost subquery, bounding the working set by batch instead of dataset.
• detectVocabularies defaults to per-property iteration (perProperty: true), reusing the per-class batchSize/maxConcurrency knobs; perProperty: false restores the single global query.
• withVocabularies now remembers which vocabularies it emitted per distribution instance, so per-property batches yield each void:vocabulary quad exactly once per stage run.
• The query file itself is unchanged – it dates from the original pipeline-void port (feat: add pipeline-void package and extend pipeline with analyzers, writers, and SPARQL utilities #48), before the per-class chunking machinery (feat(pipeline): add retry logic, perClass conversion, and tuneable concurrency #235/feat(pipeline-void): add timeout and perClass toggle to VoID stage options #236) existed; it was never deliberately kept global.

Validated against the failing dataset

Measured on the RKD Knowledge Graph index (608.3M triples, 440 distinct properties) with QLever at the production 12 GB budget:

Query	Result
Old global query	✖ out of memory (also at 16 GB)
Chunked, worst property (rdf:type, 132M triples)	✔ 38.7 s
Chunked, second-heaviest (86M triples)	✔ 24.7 s
Chunked, 10 mid-tier properties in one VALUES batch	✔ 2.7 s

BREAKING CHANGE

• The vocabularies stage iterates per property by default: a consumer transform attached via transforms[VOID_STAGE_NAMES.vocabularies] that aggregated over the stage’s complete output now sees per-batch windows (like the per-class stages). Pass perProperty: false for the old single-query behavior.
• withVocabularies is stateful per distribution instance: applying one transform instance to multiple streams for the same distribution emits each void:vocabulary quad only once.
• The shared voidStages batchSize/maxConcurrency now also apply to the vocabularies stage.

Known follow-up (pre-existing for per-class stages, now also relevant here): SparqlItemSelector requests have no retry, unlike the reader’s pRetry – a transient 5xx on a selector page fails the stage.

The integration test runs the stage chunked (batchSize: 1) and unchunked against a local SPARQL endpoint and asserts identical deduplicated output, correct per-property void:entities/void:distinctObjects, named-graph scoping of the selector, and single-emission vocabulary detection across batches.