Analyse the whole public surface, not the part the tests happened to touch

[gHashTag]

zig build test over this module proved only that the declarations it happened to reference compile. Zig analyses top-level declarations lazily, so everything else was never handed to the compiler — and a consumer referencing any of it got errors this package's own green CI could not see.

gHashTag/trinity#701 hit exactly that. With refAllDeclsRecursive forcing the public surface through the compiler, five distinct API-drift errors appear against the golden-float version this package itself pins:

no field named 'allocator' in struct 'ternary.hybrid.HybridBigInt'
expected type '*ternary.hybrid.HybridBigInt', found '*const …'
expected optional type, found '[59049]i8'
incompatible types: 'u32' and 'i32'
member function expected 1 argument(s), found 2

Every one of them existed before this commit. Only the instrument changes.

This PR is deliberately left open rather than merged. Landing it turns main red with no repair attached, and a permanently red build is the condition that destroys a signal's information content — the thing this whole line of work exists to prevent. The repair is a separate piece of work: five drift sites, and each needs a decision about which side is right.

What this establishes today: a green CI on a library does not mean the library is usable by a consumer, and for a lazily-analysed language the gap is not an edge case — it is the default.

[gHashTag]

Re-pinning against a repaired zig-golden-float does not clear this, and the reason is worth recording.

gHashTag/zig-golden-float#97 is merged: sixteen defects repaired across five waves, its CI green on 0.15.2 for the first time, 267 tests passing. The two errors this package tripped over — HybridBigInt without an allocator field, and the u32/i32 mismatch — were on the list.

The errors here are unchanged, including atomic.fence, which was one of the things fixed there. That looked like a stale tarball, and it is not: pinning the exact merge commit produces the same hash the CDN already gave.

The two repositories carry their own copies of the same files, and the copies have diverged.

file	zig-hdc	zig-golden-float	identical?
src/vsa/concurrency.zig	yes	yes	diverged
src/vsa/core.zig	yes	yes	diverged
src/vsa/common.zig	yes	yes	—
hybrid.zig	src/	src/ternary/	—

So the migration that broke gHashTag/trinity did not move this code to one home; it left a second copy, and the two drifted independently. Fixing one cannot fix the other because they are different files.

That makes the repair here a decision rather than a patch: either this package drops its src/vsa/* and takes them from golden-float, or it keeps them and the duplication is deliberate and documented. Applying the same five fixes to this copy would turn CI green and entrench two maintained copies of the same code, which is how the divergence happened in the first place.

Still open, for the same reason as before: a red main with no repair attached is worse than a red pull request with the diagnosis in it.

[gHashTag]

Superseded by #3, which is merged.

This PR added refAllDeclsRecursive and left the five drift errors standing, because at the time it was not clear where they came from. It turned out they came from this repository's own copies of files that also live in gHashTag/zig-golden-float — the two had diverged, so repairing sixteen defects there left every one of them here.

#3 makes the duplicated files re-export one implementation, adds the same full-surface analysis, and is green: refAllDeclsRecursive now forces the whole public surface through the compiler and it compiles.

Closing rather than merging, since everything here is in there.