perf: merge each unique subgraph object once, not once per occurrence

[AmitMY]

What

Gigatoken-inspired (marcelroed/gigatoken): its BPE trainer never iterates word occurrences — everything is keyed on unique words with counts. Our equivalent: duplicated words already share one subgraph object (the _build_graphs cache), but UnconnectedGraphs.merge re-ran the merge once per occurrence. Worse, on the first merge that changed a word, its occurrences diverged into equal-but-distinct copies — each then re-memoizing get_merges and re-scanning merges separately for the rest of training (measured: 16 unique words ballooning to ~290 distinct objects mid-training).

Now merge computes each distinct object's result once and reuses it for every occurrence, so duplicates stay shared (one object, one memo) for the whole run.

Benchmarks (Python 3.14, best of 3, byte-identical digests)

Zipf-distributed corpus (20k words, 2k-word vocabulary, seeded):

Case	main	PR	Δ time	Δ peak memory
BPE (300 merges)	1.92s / 35.7MB	1.61s / 31.2MB	−16%	−13%
BNE n=4 (300 merges)	2.98s / 37.8MB	2.33s / 32.2MB	−22%	−15%
Boundless (100 merges)	1.08s / 37.0MB	1.06s / 37.0MB	neutral	neutral

Honest tradeoff: an adversarial corpus where every word is unique pays ~+12% (0.39s → 0.46s) for the per-step unique-object dict. Real text is Zipf-distributed, so duplication is the norm; the win grows with corpus size / dup ratio.

Verification

• 138 tests pass, ruff clean
• Merge digests byte-identical to main on all benchmark cases

🤖 Generated with Claude Code

[AmitMY]

Superseded by the trainer-level version in #42 (per review discussion): deduping once in the trainer and training on unique subgraphs with weights is both simpler and faster than deduping inside UnconnectedGraphs.merge every step — BPE 0.074s vs 1.61s here, and it removes this PR's +12% overhead on corpora with no duplicate words. Keeping graph.py untouched.