fix(search): count only the chunk owners the caller can actually see

[rubenvdlinde]

_content_search reported a total that included chunk owners it then refused to return.

Measured on the dev instance 2026-09-02, unauthenticated, against OpenCatalogi's #[PublicPage] search:

GET /apps/opencatalogi/api/search?_search=<phrase>&_content=true
-> {"results":[],"total":1}

The owning document was soft-deleted, so the row was correctly withheld and the count was not. An anonymous caller could probe a phrase and learn from the count alone that a document containing it exists. A count is an answer, so it has to obey the same visibility rules as the rows.

Why it was like that

The over-count was deliberate and documented. Counting the distinct chunk-owner set before the resolve loop kept total stable across pages, because that loop is clamped to the page's remaining room. Stability was the right goal; the upper bound was the wrong way to reach it. Scope mismatch, RBAC, tenancy and a soft-deleted owner each drop a row without touching the count.

The change

Resolve first, then count and page. Every candidate is resolved, total counts what resolved, and the page is a slice of that same set.

Stability is preserved, and is now a property of the query rather than a guess: page 1 and page 3 resolve the same candidates and report the same number. The existing cross-page test (53 across page one and page three) passes unchanged.

Cost, stated plainly

Up to CHUNK_CANDIDATE_LIMIT (50) resolves per call instead of up to the page's room. That is the worst case this class already budgets for and documents on that constant, and _content_search is opt-in.

Verified

	before	after
invisible owner, anonymous	total: 1, rows: 0	total: 0, rows: 0
visible owner, authenticated	total: 1, rows: 1	total: 1, rows: 1

Both measured live. The positive control matters: a fix that just zeroed the count would pass the first row and fail the second.

Six tests asserted the over-count as intentional. They are rewritten, not deleted — each now pins the visibility rule it was documenting the absence of. The clamping test additionally proves the page is still clamped while the total still counts the resolvable owner.

PHPUnit 14/14 plus the sibling QueryHandlerContentSearchTest 12/12; PHPCS, PHPStan, PHPMD and Psalm clean.

🤖 Generated with Claude Code

[github-actions]

Quality Report — ConductionNL/openregister @ 20dbc60

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-specs		✅
test-l10n		✅
test-l10n-parity		✅
format		✅
check-schema-l10n		✅
check-l10n-js		✅
composer			✅	✅ 174/174
npm			✅	✅ 543/543
app:check-code	⏭️
info.xml	✅
REUSE	❌
PHPUnit					❌
Newman					✅
Playwright					⏭️ deferred — runs on the promotion into beta/main, not on a pull request into development
Hydra gates					✅

---

Quality workflow — 2026-09-02 11:13 UTC

Download the full PDF report from the workflow artifacts.

[github-actions]

Quality Report — ConductionNL/openregister @ 0cb6873

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-specs		✅
test-l10n		✅
test-l10n-parity		✅
format		✅
check-schema-l10n		✅
check-l10n-js		✅
composer			✅	✅ 174/174
npm			✅	✅ 543/543
app:check-code	⏭️
info.xml	✅
REUSE	❌
PHPUnit					✅
Newman					✅
Playwright					⏭️ deferred — runs on the promotion into beta/main, not on a pull request into development
Hydra gates					✅

---

Quality workflow — 2026-09-02 11:30 UTC

Download the full PDF report from the workflow artifacts.