One embedding refresh per base at a time

[WaylandYang]

Closes #282.

Creating a base with three packs enqueues three embed_ontology jobs. With worker concurrency at 64 they ran at the same time, each read the same set of terms still missing a vector, and each embedded all of them: 3,752 terms embedded three times in the report on #282.

Refreshes for one base now take turns. A per-base tokio::sync::Mutex (in a process-wide table) is held for the duration of refresh_scoped; a job that arrives while another is running waits, then re-reads the missing set, which by then is empty or holds only the terms added after the first job read its set. Waiting rather than skipping means nothing is left for a later refresh to pick up. Different bases are unaffected.

A unit test pins the behaviour: two refreshes of one base serialise, another base is not blocked.

cargo fmt, cargo clippy -D warnings, cargo test -p utopia-server ontology_index pass.

🤖 Generated with Claude Code