fix(vector): read on-disk embeddings through the scan state's transaction

[aikins01]

OnDiskEmbeddings::constructScanState takes an optional transaction that overrides the one the embeddings were built with, but getEmbedding and getEmbeddings ignored it and used the member transaction for visibility, the committed/uncommitted source, scan-state setup and the lookup. A caller passing a different transaction would get visibility from one transaction and rows from another. Every current caller passes the same transaction, so nothing changes today.

OnDiskEmbeddingScanState now keeps the transaction it was built with, and both lookup paths read through it, the same way the cached quantized embeddings already resolve visibility.

Depends on #95 and should merge after it; the first commit here is #95's. Like #95, CI builds against the latest successful core Build and Deploy run on main, which predates LadybugDB/ladybug#1113, so it won't compile until that workflow next succeeds.

[adsharma]

Follow-ups (non-blocking, reviewed pr95..pr101):

1. Adopt Transaction::tryGetLocalRowIdx (core perf(transaction): resolve a node's local row with one local-table lookup ladybug#1155, merged) in getEmbedding — replaces the isUnCommitted + getLocalRowIdx pair (2–3 getLocalTable lookups) with one. That core PR explicitly names this call site.
2. Consider DASSERT(transaction != nullptr) in OnDiskEmbeddingScanState ctor — TableBackedQuantizedEmbeddings::constructScanState has one; here a null member + null override would null-deref at isUnCommitted instead of failing fast.
3. Pre-existing asymmetry, out of scope: single path uses isVisibleNoLock, batch path uses locking isVisible, and batch never flips source/nodeGroupIdx itself (relies on lookupMultiple internals). Flagging so it isn't lost.