Export packed_vsa — present, correct, and reachable from nowhere

[gHashTag]

src/vsa/packed_vsa.zig defines packedBind, packedUnbind, packedBundle, packedCosineSimilarity and randomPackedVector. None of them were reachable: root.zig did not export the file and vsa/core.zig did not re-export it.

A downstream package that wants those functions therefore has to vendor a copy of the file — which is how the copies in this fleet started diverging in the first place. Same shape as the vsa_jit export in #98: the code is present and correct, and nothing can reach it.

zig build clean.

[gHashTag]

The export earned its keep immediately. Making packed_vsa reachable made
the compiler look at it for the first time, and it found four more imports
that could not resolve:

src/vsa/hybrid.zig:1:1: error: unable to load 'hybrid.zig': FileNotFound
src/vsa/knowledge_graph.zig:1:1: error: unable to load 'knowledge_graph.zig': FileNotFound
src/vsa/packed_trit.zig:1:1: error: unable to load 'packed_trit.zig': FileNotFound
src/vsa/vsa.zig:1:1: error: unable to load 'vsa.zig': FileNotFound

Three were misplaced paths: hybrid and packed_trit are in ../ternary/,
and there is no vsa.zig at all — bind, bundle2 and randomVector are
in the sibling core.zig.

The fourth is worth naming separately. knowledge_graph.zig is not in this
repository; it is in gHashTag/zig-knowledge-graph, and that file opens
with const packed_vsa = @import("packed_vsa.zig"); — which does not exist
there either. One directory was split into two repositories and every
relative import was left pointing at the sibling that stayed behind, so
neither half compiles. Filed separately.

The dependency was also inverted: a VSA primitive should not need a type
from a knowledge-graph consumer. The three tests used Entity.hashString
only to derive a seed, and that function is five lines of djb2. Reproduced
verbatim in place, so the seeds — and therefore what the tests assert — are
unchanged.