security(spp_api_v2): search next offsets are database positions, so consent-filtered clients can count hidden records [Severity: Low/Medium] #576

Describe the bug

After #555, meta.total never counts hidden records. But next/_offset are raw database positions, so for any
filter, next_offset - offset - len(data) is the number of hidden rows passed over on that page. With _count=1:

• rows [V, H] give V with next, then an empty last page, which proves one hidden match exists after V;
• [H1, H2, V] returns V at offsets 0, 1 and 2, so there are exactly two hidden rows before it;
• _sort=-name on /Individual turns the ambiguous tail into the head.

A single hidden identifier= match does not leak. This is the D10 trade-off accepted in #555.

Expected behavior

An opaque cursor (HMAC'd or encrypted position, or keyset on the last examined id inside an opaque token), with
_offset as a logical position for consent-filtered clients. Related: #559, #560.

Found while checking OpenSPP2 REST API v2 against the OpenFn @openfn/language-openspp v4 adaptor (#554, PR #555); not fixed in #555.