fix(spaces): gate invalidation checks on the delta and cap their server time

[tkuhn]

Why

On 2026-09-24 a routine space admin grant made AuthorityResolver's preset-deactivation check never finish on rdf4j 6.1.0. The client gave up after its 60 s socket timeout, but rdf4j kept evaluating the abandoned query, and the cycle retried it every tick. On petapico it was started 77 times over 85 minutes, none finished, and the pile-up took the fleet down. The rdf4j request logs show the same store answered the identical query in 10 s on lmdbpool4 right after the rollback. The 6.1.0 hang itself does not reproduce offline (a copy of that store in a fresh 6.1.0 process answers in 6 s), so this PR makes the cycle robust against it on any version rather than fixing rdf4j.

What

• Gates (AuthorityResolver.DeltaKinds). Every check in applyInvalidations needs one kind of record among the new loads: an invalidator, a preset assignment, a role revocation or a role detachment. The cycle now reads which kinds the delta holds with four two-pattern ASKs and runs a check (and the two invalidator-based deletes) only when its kind is present. Each gate is a sub-pattern of its check's own WHERE clause, so skipping is exact. Load counter and load data commit in one transaction, so a gate evaluated after the counter is read sees every load the check would.
• Server-side time limit. The checks, invalidation deletes and tier inserts carry setMaxExecutionTime equal to the client's socket timeout (now the shared TripleStore.SOCKET_TIMEOUT_SECONDS, 60 s). It never cuts off a request that succeeds today; it stops rdf4j from evaluating a request the client has already abandoned. An update stopped this way rolls back as a whole, so a timed-out cycle can no longer leave half its writes behind.
• Docs: the 6.1.0 paragraph in deployment-rationale.md gets the log findings and the mitigation; one sentence in design-role-revocation.md no longer says the displacement DELETE runs every cycle.

Validation

• On a consistent copy of petapico's spaces store, for the outage cycle (graph _3565, lastProcessed 3568): all four gates return false in ≤ 20 ms on both 6.1.0 and lmdbpool4, so none of the 11 checks or 2 deletes would run. Over the whole load history the gates return true where those records exist, still in ≤ 20 ms.
• rdf4j honours the timeout parameter for queries and updates over HTTP; both versions aborted at the limit with a 503 in local tests.
• InMemoryTripleStore now records the ASK/UPDATE texts production code prepares. New pipeline tests: gates only see records inside the delta; an admin-grant delta runs exactly the four gates; a delta holding every kind runs all 17 operations for real (keeps the proof that every check parses and executes, which the empty-graph test no longer gives); an invalidation through its gate still deletes the row and raises the rebuild flag.
• mvn test: 522 tests, 0 failures.

Not covered

• The tier inserts and the late-arrival sweep are not gated, only time-limited. The attachment-tier insert is what timed out on nanodash.net that day, so a gate there is a possible follow-up.
• If 6.1.0's hang is in query planning rather than evaluation, the time limit may not interrupt it. The fleet stays on lmdbpool4.

🤖 Generated with Claude Code