[prabhu]

Fixes #21.

GraphFragmentCodec.encode read the properties of any node that is not a DetachedNodeGeneric by reflection, and wrote the node with no properties when that failed. In atom's native image it always fails for cpg2's generated New* nodes, so native builds cached fragments holding only node labels and built later graphs from them (AppThreat/atom#286). Scala collection values were also iterated by reflection, which throws in a native image.

I triaged it with fixtures in GraphFragmentCodecPropertiesTest. On main, four cases write a fragment whose node lost its properties: the private class from the issue, a node class without properties(), one whose properties() throws, and such a node reached only as an edge endpoint. Two more are right only because reflection works on the JVM. The other four throw instead of returning empty: an unsupported value type, an unsupported edge property, a property pointing outside the fragment, and malformed key-values.

The codec now uses no reflection at all. It reads a DetachedNodeGeneric's key-values directly and every other node through a PropertyReader the caller passes, once per node. Anything it cannot write exactly makes encode return empty, the same contract it already had for diffs that are not add-only or self-contained. A caller then recomputes instead of caching a lossy fragment, and the JVM and a native image behave the same. The three-argument encode stays for diffs of generic nodes. Scala collection values are no longer accepted; a reader for Scala nodes converts them to java.util.List.

I checked it end to end with native images built with GraalVM CE 25.0.2. Each run went cold (writing fragments), then warm (reading them back), then --cache none for reference. With chen main and odb2 main, the warm native run on a Python project (DefectDojo's dojo/tools) spun at full CPU until I stopped it after 575 s. On libexpat it exited 0 with 530 slices, none of which matched the 727 from the uncached run. With this change plus a chen reader for New* nodes, the warm runs give byte-identical slices on the Python and JS projects, on the JVM and natively. C warm runs differ in about 62 of 727 slices both before and after this change, on the JVM too; that is a separate, pre-existing issue in C fragment restore.

chen needs a matching change before it picks this up. Its AstFragment must pass a reader for cpg2's New* nodes, or nothing gets cached. I have that on a chen branch with a cache-key revision, so fragments that earlier native builds wrote are not read again. It replaces the diff copy in AppThreat/chen#223 and goes up once this is released through cpg2. The version stays 3.1.1, unreleased, alongside #22. All tests pass with testFull: 102 JUnit tests and 185 ScalaTest tests.