fix: the context engine's lazy setup is race-free

[mekjr1]

TestAssemblerLazyInitRace failed CI's go test -race job four times on 2026-10-07: twice on main (runs 37561008993 and 37568246076) and twice on PR branches (37652983718 and 37662881723). The race detector reported a real race, not a timing problem.

Engine.initAssemblerOnce and initCompactionOnce (pkg/seahorse/short_engine.go) checked the field before taking the mutex. That's double-checked locking, which Go's memory model doesn't allow. The read outside the lock races with the write inside it. A caller that saw the new pointer could also use the Assembler before its fields were visible to it, which can happen on arm64.

Now loadAssembler and loadCompaction read the field, and create it if needed, under their mutex every time, and return it. Assemble, Compact and CompactUntilUnder call them. After the first use the lock is uncontended, and its cost is nothing next to the database work around it. Close already read compaction under the lock.

Tests: TestCompactionLazyInitRace does for the compaction engine what TestAssemblerLazyInitRace does for the assembler. Under -race in a Linux container (golang:1.26.6):

• the old code failed TestAssemblerLazyInitRace once in 5 runs;
• with the check outside the lock put back into loadCompaction, the new test reported the race within 10 runs;
• with the change, both tests passed 10 runs, and the whole package passed under -race.

Internal only; no CHANGELOG line.

[mekjr1]

Superseded by #63, which includes this change or replaces it.