docs(changelog): the two entries missing from #1792 and #1793

[lmeyerov]

Remediation from the audit of the six merges that landed without recorded approval (#1782, #1783, #1784, #1790, #1792, #1793). Docs only — no code touched.

What the audit found, in one line

No correctness regression in any of the six. 707/707 non-cypher differential cases (12 random graphs × 14 chain shapes × {pandas, polars} × {scan, index_policy="force"}, with duplicate node keys, dangling edges and null-carrying columns) are byte-identical between 84be35fb (pre-stack) and 233b64c8; the 37 that differ are #1793 fixing a real bug, reproduced independently. The defects are in process, not in behaviour.

What this PR fixes

The two missing CHANGELOG entries. #1793 is the one that matters — it fixes a silent wrong answer that is user-visible on every engine, and it was the highest-value entry of the six.

Reproduced on the pre-fix tree so the entry states a measured effect rather than a description:

MATCH (a {grp:1}) WITH a MATCH (a)-[]->(b) RETURN count(*)
MATCH (a)-[]->(b) RETURN count(*)          # same graph object

seed	correct	got (pre-fix)
0	134	60
1	136	69
2	143	61
3	129	88

On polars the poisoned graph then raised NotImplementedError for every subsequent query — a failed query left the user's object broken. Both fixed on master; neither written down.

#1792's graphviz half (KeyError: None → an actionable ValueError on a bound-but-unlabelled frame) is smaller but is still a user-facing error-message change, so it gets an entry too.

Deliberately NOT included

The audit also flagged #1792's dtype: object → dtype: DType as a typing widening (DType = Any, strictly weaker than object; mypy is indifferent between them here — verified by running both). I am not reverting it. graphistry/compute/typing.py declares DType as the repo's engine-agnostic dtype alias, with the comment "Honestly Any — the concrete type is engine-dependent", and these parameters do receive pandas/cuDF/polars dtypes. So the named alias is the documented convention even though it checks as Any. Reverting on the audit's reading would churn against a stated convention on a judgement call that belongs to the owner — reported here rather than silently decided.

Other audit findings, filed separately rather than bundled

• GFQL: a DANGLING DESTINATION is matched by pandas/cuDF and dropped by polars — silent cross-engine divergence #1808 — pre-existing: a dangling destination is matched by pandas/cuDF and dropped by polars (MATCH (a)-[]->(b) on a 2-edge graph: pandas 2, polars 1). Verified identical on 84be35fb and 233b64c8, so not from these PRs. polars is the correct one, which means the parity suites are calibrated against the wrong oracle for this shape.
• Test-lane dead zones — every polars assertion in perf(gfql/polars): stop deduplicating semi-join key sides #1784's, fix(gfql): the indexed bypass and the named-middle rewrite must not discard rows() params #1790's and fix(gfql): stop WITH re-entry mutating the caller's Plottable (#1786) #1793's regression suites was dead in CI, because their files were absent from bin/test-polars.sh and test-gfql-core installs no polars. Fixed in the CA4 allowlist PR and in the fix(gfql): rows(table=...) must survive a named middle on both chain surfaces #1788/fix(gfql): the indexed bypass and the named-middle rewrite must not discard rows() params #1790 engine-parametrization PR.
• Vacuous coverage on perf(gfql/polars): stop deduplicating semi-join key sides #1784 — reverting all 7 .unique() removals leaves test_engine_polars_semi_key_dedup.py at 36 passed: the PR's own suite pins the boundary (removing the how="left" feeder's .unique() correctly fails 14) but not the change. Its perf-regression theory was tested and refuted: at N=3000/E=3,000,000 the undirected semi build side went 235.0 → 235.1 ms.
• Untested disclosed risk on perf(gfql): evaluate indexed edge_match on candidate rows, not the whole edge frame #1782 and perf(gfql): empty-left merge shrink + polars EORD/EID row-index dedup #1783 — perf(gfql): evaluate indexed edge_match on candidate rows, not the whole edge frame #1782's CHANGELOG admits the indexed path can now succeed where the scan raises, and no test pins it (I could not construct a repro either). perf(gfql): empty-left merge shrink + polars EORD/EID row-index dedup #1783's polars EORD=EID hunk is invisible to all 1003 polars chain tests when reverted.

Runtime delta: zero

One file changed, and it is CHANGELOG.md. Per CB5 no pyg-bench lane run is required, and that is checkable from the diff.

🤖 Generated with Claude Code

https://claude.ai/code/session_015YsqAZQLbqjSDrYSFz2GoB