[Feature] Add Distributed Posting Router for SPANN

[TerrenceZhangX]

Limitations

1. Using buildOnly flags to mitigate no ditributed build limitation. Current flow is using buildOnly to let single node to build and distribute to other nodes. Then using disable buildOnly to let multiple nodes load same head index and run benchmarks.

Scale results

Dataset: SIFT1B bigann_base.u8bin, 128d UInt8, L2. SPANN 2-layer index,
4 search threads, 4 insert threads, top-K=5, 200 queries.

1M base + 1M insert

Metric	1node	2node	Scale
Build time (s)	74.2	91.3	0.81×
Pre-insert QPS	429.3	696.3	1.62×
Pre-insert mean latency (ms)	9.26	8.63	—
Pre-insert p99 (ms)	27.31	29.18	—
Post-insert QPS	425.0	708.1	1.67×
Insert throughput (vec/s)	~900	1793	—
Recall@5 (pre-insert)	0.984	0.978	—
Recall@5 (post-insert)	0.983	0.984	—

Notes:

• Build is slower on 2node at 1M scale: the cross-node coordination
  overhead (head-sync RPCs, control plane) dominates when there are only
  ~40k head vectors to build.
• Search scales well already at 1M; recall is unchanged.

100M base + 1M insert

Metric	1node	2node	Scale
Build time (s)	15292	16264	0.94×
Pre-insert QPS	183.3	360.5	1.97×
Pre-insert mean latency (ms)	21.56	21.92	—
Pre-insert p99 (ms)	32.81	39.55	—
Post-insert QPS (round 2)	183.2	337.2	1.84×
Insert throughput (vec/s)	738	1285	1.74×
Recall@5 (pre-insert)	0.912	0.904	—
Recall@5 (post-insert)	0.912	0.904	—

Notes:

• Search scales near-linearly (1.97×) at the target scale — the per-node
  query partition + remote KV reads are well-balanced.
• Insert scales sublinearly (1.74×), expected: every insert that
  promotes/splits a head triggers head-index sync across nodes, which is the
  current bottleneck.
• Build is essentially flat (0.94×): build is dominated by per-node local
  graph construction; 2node has additional head-sync but no work split, so
  near-no scaling here is expected for the current single-builder design.
• Recall is stable across configurations (within 0.01).

[MaggieQi]

why search need to be changed?

[TerrenceZhangX]

Each node's local m_count tracks only its own AddIndex progress, not peers'. When search reads a TiKV posting whose bytes were written by a peer running ahead of us, those record VIDs can fall above our local m_count. GetVersion short-circuits any VID >= m_count to 0xfe, so without growing m_count first the post-heap filter would drop those records as deleted and recall would silently regress. This loop grows m_count just enough to cover the largest VID we actually fetched

[MaggieQi]

Even though it is not local and not layer 0, it still needs to do mergeasync.

[TerrenceZhangX]

Agree. This is over-simplification. Fixed to mergeAsync trigger based on headID owner.