Bump maven-gpg-plugin from 1.6 to 3.0.1 - #52

Bumps [at.yawk.lz4:lz4-java](https://github.com/yawkat/lz4-java) from 1.11.0 to 1.11.1.
Release notes

*Sourced from [at.yawk.lz4:lz4-java's releases](https://github.com/yawkat/lz4-java/releases).*

> lz4-java v1.11.1
> ----------------
>
> **Security release for [CVE-2026-59949](https://github.com/yawkat/lz4-java/security/advisories/GHSA-xx22-p4ch-683r).**
>
> What's Changed
> --------------
>
> * Fix docs code block line breaks by [`@​yawkat`](https://github.com/yawkat) in [yawkat/lz4-java#52](https://redirect.github.com/yawkat/lz4-java/pull/52)
>
> **Full Changelog**: <yawkat/lz4-java@v1.11.0...v1.11.1>


Commits

* [`dbd86d0`](yawkat/lz4-java@dbd86d0) Merge commit from fork
* [`5a5bd58`](yawkat/lz4-java@5a5bd58) Fix docs code block line breaks ([#52](https://redirect.github.com/yawkat/lz4-java/issues/52))
* See full diff in [compare view](yawkat/lz4-java@v1.11.0...v1.11.1)
  
[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility\_score?dependency-name=at.yawk.lz4:lz4-java&package-manager=maven&previous-version=1.11.0&new-version=1.11.1)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
Dependabot commands and options
  
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot show  ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

…n none

The user asked whether we measure memory and disk. Memory: yes, 380/380
canonical rows since the #52 fix, anonymous working set from cgroup v2 rather
than RSS. Reported: barely. Four tables, not one memory column; three prose
sentences in the whole paper; zero mentions on the project page, whose 31
metric columns did not include one.

The reason is ordering. The metric was fixed AFTER the tables were designed
(memory.peak counted reclaimable page cache and read Elasticsearch as pegged
at 20 GB), so once the numbers were trustworthy they went into prose where
they made a point, and nobody went back to add a column. The page inherits
its columns from the tables, so a missing column propagated into a missing
metric.

Now: T3 grows a Peak anon (GiB) column, and the page's graph table grows
"peak memory GiB". Both read peak_anon_mib_sum, which is server+client for a
served backend and the single process for an embedded one, so both
deployments report the whole engine rather than half of it.

WHAT THE COLUMN EXPOSES, and the reason it is worth the width: the prose said
ArcadeDB uses 37% less than Neo4j and left LadybugDB as "lightest on both
axes". The column prints 0.365 GiB against our 8.06 at SF10, so LadybugDB
uses twenty-two times less, which is a far larger margin than the one we
quoted. Three claims now pin all three engines, including ours.

TWO THINGS THIS CHANGE FOUND:

 1. A duplicate-row defect I introduced and then caught. The page's l2 table
    does not group on `gav`, so ArcadeDB's SF10 OLAP cell is two rows,
    view-on and view-off. That stayed invisible while every metric in the
    table was OLTP-only and the OLAP rows came out empty; adding a metric
    that EVERY row has made the pair appear, identical in every printed
    field. Fixed by scoping l2 to oltp, since the l2olap table already
    carries the ablation with the right grouping. General lesson: a metric
    present for all rows exposes any grouping key a table is missing.

 2. T4 sparse CANNOT have this column yet. Its ArcadeDB rows come from the
    results/sparse_2681 overlay, which records mem_cap (the ceiling we set)
    and not peak anon (what was used). A column there would print real
    numbers for every comparator and blanks for us, which is worse than no
    column. It waits for the freeze re-run.

Units: _agg now divides MiB->GiB for the two anon fields, once and centrally,
so a column headed GiB cannot print 8256.

CROSS-CHECKED, artifact = paper table = project page, all eight graph cells:
  arcadedb_emb  sf1 1.256 / sf10 8.064
  arcadedb_srv  sf1 3.393 / sf10 7.875
  neo4j         sf1 4.607 / sf10 12.928
  ladybug       sf1 0.223 / sf10 0.365

Gates: claims 108/0, page_check 4/0, provenance 0 BAD, fairness 0.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01E2Ytwsz6uQvs1dBoqGBSrV

…cture

The user asked whether "13.2 GiB against 0.14, a factor of 98" was a
legitimate comparison. It is not, and neither was the 107x I corrected it to
an hour earlier.

  ArcadeDB   heap 16g, set by HEAP_BY_SCALE["medium"]
  PostgreSQL server_env is password + db name, so shared_buffers stays at the
             image default of 128 MB
  measured postgres peak anon = 0.119 GiB, which IS that 128 MB
  postgres TOTAL peak = 3.85 GiB; the rest is kernel page cache

Two defects in one number. We configured our heap and left PostgreSQL's buffer
pool alone, so the ratio prices a choice of ours. And anonymous accounting
excludes the page cache where PostgreSQL keeps its working set by design.

The fraction of peak that anon captures, across our own comparators:
  postgres 26%, qdrant 48-61%, milvus 49-55%, chroma 64%, lancedb 68%,
  elasticsearch 75%, ladybug 78%, duckdb 84%, neo4j 95%, arcadedb 84-98%.
A ratio between a 26% engine and a 98% engine is not a memory comparison.

Note the direction: this systematically overstates our losses against
page-cache engines. The honest picture is more favourable to us than what we
were printing, which is not a reason to relax about it.

Not a simple revert to total, either: #52 moved off memory.peak because it
counts reclaimable cache and had Elasticsearch pegged at 20 GB. Total
overstates for engines that opportunistically fill cache, anon understates for
engines that deliberately live in it, and no single number is fair across six
architectures.

claims_check drops mem.ratio.postgres and pins the confound instead:
mem.anon_share.postgres 0.262 and mem.anon_share.arcadedb_graph 0.975, so a
future reader who recomputes the ratio finds the reason rather than a claim.

Open in #150: whether the tables should print total beside anon (the data is
already there), whether PostgreSQL's untuned buffer pool moves its latency
too, and that fairness_check has no notion of a memory knob that is not a heap.

Gates: claims 114/0, page_check 4/0, provenance 0 BAD, fairness 0.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01E2Ytwsz6uQvs1dBoqGBSrV

…ry column

Two gaps that the next campaign would otherwise bake in for another cycle.

ON-DISK SIZE (#149). The campaign plan listed it from the start, beside
latency, recall and peak RSS, and no lane ever recorded it. For a storage
engine that is a strange thing to omit: index size is half of what makes an
index choice a tradeoff, and it is the axis where sparse int8 quantization
should show its win.

Measured as the container's writable layer (docker inspect --size SizeRw),
not by du-ing a data directory. A per-backend data path is a per-backend
ASSERTION: eight engines, eight guesses, and a wrong guess returns a
confident zero instead of an error. The writable layer needs no path, reads
the same for an embedded engine writing to /tmp and a server writing to
/var/lib, and comes from the daemon. It correctly excludes the read-only
image layers and the bind-mounted corpus, since /data is mounted read-only
and the input is not the engine's storage.

Sampled twice: baseline right after ready, final before teardown. PostgreSQL
writes ~50 MB in initdb before a row is loaded, so disk_data_mb (final minus
baseline) is what the workload actually cost, with both raw numbers kept
beside it so the subtraction is visible rather than baked in. Taken before
the containers are removed, because the writable layer goes with them.

Verified against a real container: 120 MiB written reads 120.0, and an
unknown id returns None rather than 0.

Also initialised cli_cid at the top of the function. The finally block reads
it and a server that fails to start returns before the client exists, so
leaving it unbound would have turned a recorded server_not_ready row into a
NameError that loses the cell.

OVERLAY MEMORY (#113). sparse_multipass_driver and dense_multipass_driver
now run SelfMemorySampler, which is why T4, T5 and four of the eleven page
tables have no memory column while every lane has measured it since #52.

Started before the build, not around the query passes: an index build is
where a vector engine's memory peaks, and a column that reported steady
state would not mean what the lane column means. finish() is called ONCE
after every pass and stamped onto all of them, because calling it in the
loop would stop the sampler on pass 0 and freeze every later row at whatever
the peak was before the warm passes ran.

deployment_decomp_probe is untouched: it runs three arms in one process, so
one cgroup peak cannot be attributed to any of them.

Gates: claims 116/0, page_check 4/0, provenance 0 BAD, fairness 0.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01E2Ytwsz6uQvs1dBoqGBSrV