Upgrade the DataScript demo to EACL v8

[theronic]

Summary

• pin the DataScript demo to EACL PR #96 at 73c5488ce35f949f471670f115b5fdccea4b1ec2
• retain EACL v8's default client-private exact-current cache, Relay pagination, and immutable :eacl/id identity contract
• incorporate PR #96's adversarial serialization, malformed-cursor, cache-admission, idempotent-schema-write, and CI fixes
• rerun the 10,000-server browser benchmark three times and record the PR #96 results without attributing the measured paginated-query regression before profiling

Verification

• browser ClojureScript suite: 36 tests, 174 assertions, 0 failures, 0 errors
• :app and :test browser builds: 0 warnings
• live 10,000-server smoke test: 2 visible accounts, 8 teams, 4 VPCs, and 4,000 servers for user-1:admin
• every benchmark sample validates the expected allow/deny, page size, or exact count
• fresh-runtime cache telemetry: 6,245 exact-current hits, 5 misses, 5 puts, and zero managed-current hits, bypasses, stamp failures, or admission entries
• all EACL PR #96 GitHub checks pass

PR #96 query-cost result

Times are p50 microseconds per invocation from fresh default-cache runtimes:

Workload	PR #95	PR #96	Change
Direct authorization allow	34	34	unchanged
Recursive authorization allow	30	32	6.7% slower
Recursive authorization deny	28	30	7.1% slower
Lookup visible server page (20)	3,540	4,500	27.1% slower
Count 4,000 visible servers	26	24	7.7% faster
Read 20 of 2,000 account/server relationships	17,640	19,200	8.8% slower
Read known-user relationship page	2,680	3,340	24.6% slower

Two additional PR #96 runs measured 4.46–4.82 ms for lookup, 18.40–18.93 ms for the broad relationship page, and 3.40–3.41 ms for the known-user page. The paginated-query slowdown is repeatable in this browser session. PR #96's stricter secure-format and cursor validation is a plausible contributor, but these end-to-end measurements do not isolate causation.

The cache redesign remains effective: authorization and completed-count cache hits stay in the tens of microseconds and cache telemetry matches PR #95. Detailed method, historical baselines, and caveats are in docs/eacl-v8-query-benchmark.md.

[theronic]

EACL query benchmark: v7 baseline vs v8 upgrade

Measured in one Chromium process against fresh, independently seeded Explorer runtimes with 5 accounts, 20 teams, 10 VPCs, 10,000 servers, and 38 users. Each workload used 20 warm-ups and 30 measured samples; seeding and relationship writes/deletes were excluded. v8 used {:cache cache/no-cache :proof-mode :none} so this comparison explicitly measures uncached EACL/DataScript query execution rather than secure cache-proof construction.

Times are microseconds per invocation. Factor is v8/v7, so values above 1 are regressions.

Workload	v7 p50	v8 p50	p50 factor	v7 p95	v8 p95	p95 factor
Direct authorization allow	34	466	13.71×	46	796	17.30×
Recursive authorization allow	88	888	10.09×	92	976	10.61×
Recursive authorization deny	352	1,128	3.20×	372	1,168	3.14×
Lookup visible server page (20)	1,040	5,480	5.27×	1,140	6,020	5.28×
Count 4,000 visible servers	11,800	25,800	2.19×	18,600	26,500	1.42×
Read account→server page (20 of 2,000 matches)	170	88,840	522.59×	210	91,970	437.95×
Read known-user relationship page (20)	240	3,180	13.25×	290	3,290	11.34×

No measured read workload is faster on v8. The severe outlier is broad relationship pagination: DataScript v8 materializes and canonically sorts all 2,000 matches, then builds a cursor proof over the full ordered match set to return 20 rows. This makes each page O(matches), and a complete fixed-size traversal O(matches × page-count).

The benchmark found an additional duplicate cost: EACL separately hashed the same complete match set for start and end cursors. Upstream EACL commit 7df4d4be4f014786662197248f8c5ddbef17ab65 now reuses one proof per read and asserts that behavior. Under the same interim client configuration, it reduced the broad relationship-read median from 159.68 ms to 84.13 ms (47.3%) and the small relationship-read median from 4.67 ms to 3.00 ms (35.8%). The final explicit no-cache client measured 88.84 ms and 3.18 ms respectively. The remaining full-result materialization/proof cost is unresolved and should be treated as the principal query-performance blocker.

The reproducible harness and complete method are committed in test/eacl/bench/query_benchmark.cljs and docs/eacl-v8-query-benchmark.md.

[theronic]

Reran the Explorer browser benchmark after upgrading to EACL PR #95 at bb69a6bd17252bad6d9f2aacdd65a70cb9832c50.

The default exact-current cache is a material improvement:

• direct allow: 466 µs → 34 µs p50
• recursive allow: 888 µs → 30 µs
• recursive deny: 1,128 µs → 28 µs
• lookup page: 5,480 µs → 3,540 µs
• cached count of 4,000 results: 25,800 µs → 26 µs
• relationship page, 20 of 2,000 matches: 88,840 µs → 17,640 µs

The matching no-cache + proof-mode :none run measured 184, 264, 632, 6,000, 25,696, and 17,540 µs respectively. This separates the completed-answer cache win from the underlying engine: uncached can? is substantially better, while uncached lookup/count are not.

Correctness/telemetry:

• 36 browser tests, 174 assertions, zero failures/errors
• 6,245 exact-current hits, 5 misses, 5 puts
• all benchmark samples validated their expected semantic result
• live 10,000-server Explorer smoke test produced the expected 2/8/4/4,000 visible resource counts with no browser warnings/errors

The remaining broad relationship-read cost is outside the cache. PR #95 removed the complete-result cursor digest, but DataScript still materializes and sorts all 2,000 matches before returning 20, leaving that workload about 104× slower than v7.

Full results and method: docs/eacl-v8-query-benchmark.md

Upstream caveat: EACL PR #95's top-level tests and formal-model jobs pass, but its isolated-module/parity jobs are currently red from root-relative fixture/tool-path setup failures. The dependency PR is not yet all-green.

[theronic]

Upgraded the Explorer to EACL PR #96 (73c5488ce35f949f471670f115b5fdccea4b1ec2) in a0947c4.

Validation remains green:

• 36 browser tests / 174 assertions / 0 failures / 0 errors
• app and test builds compile with 0 warnings
• live 10,000-server smoke test returns the expected 2 accounts, 8 teams, 4 VPCs, and 4,000 servers
• fresh cache telemetry remains 6,245 exact-current hits, 5 misses, and 5 puts

I also repeated the query benchmark three times. Cached authorization and completed-count performance are effectively preserved, but paginated queries are consistently slower than the earlier PR #95 run:

Workload	PR #95 p50	PR #96 p50
Direct allow	34 µs	34 µs
Recursive allow	30 µs	32 µs
Recursive deny	28 µs	30 µs
Lookup page (20)	3.54 ms	4.50 ms
Count 4,000 servers	26 µs	24 µs
Read 20 of 2,000 relationships	17.64 ms	19.20 ms
Read known-user page	2.68 ms	3.34 ms

The two additional PR #96 runs put the three paginated workloads at 4.46–4.82 ms, 18.40–18.93 ms, and 3.40–3.41 ms respectively. That makes the regression repeatable in this session, but the benchmark does not prove whether stricter secure-format/cursor validation is the cause. The full measurements and caveats are committed in docs/eacl-v8-query-benchmark.md.