## Summary

- Fix a TOCTOU race condition in `tp_leader_process_buffers()` that can
silently lose documents during parallel index builds. The leader
collected ready buffers *before* checking `workers_done`, allowing a
window where a worker marks its final buffer READY and increments
`workers_done` between the two reads — causing the leader to exit
without processing the final buffer.
- Fix a latent deadlock where `shared->nworkers` was set to the
*requested* worker count but never updated to the *actually launched*
count. If Postgres launched fewer workers, `workers_done` could never
reach `nworkers`.
- Update expected test output for the build-completed NOTICE format
change from #214.

### The race

```
Leader:                              Worker (finishing):
                                     1. Mark final buffer READY
                                     2. SpinLock → workers_done++
1. Collect buffers → num_ready=0
   (missed the READY buffer)
2. Check all_done → true
3. num_ready(0) > 0 → false → skip
4. while(!all_done) → EXIT
   *** FINAL BUFFER NEVER PROCESSED ***
```

### The fix

Check `workers_done` *first* (under SpinLock, providing the memory
barrier), *then* collect buffers. Workers set buffer READY before the
SpinLock acquire around `workers_done++`, so after the leader's SpinLock
release, all final buffers are guaranteed visible. The loop now exits
only when `all_done && num_ready == 0`.

### Impact

On MS-MARCO (8.8M passages), this race non-deterministically lost ~4M
documents (~45% of the corpus). One CI run indexed only 4,834,444
documents while the same data loaded correctly in another run (8,841,770
documents). The root cause was discovered while investigating benchmark
validation failures in #239.

## Testing

Regression tests pass (47/47). The race is non-deterministic so it
cannot be reliably reproduced in unit tests — validation should be done
via the MS-MARCO benchmark pipeline which exercises parallel builds at
scale.