Tighten the dense selection as its heap fills

[drametwally]

The dense scorer made a result for every row of the matrix and let the bounded heap discard almost all of them. Scan and inverted both raise their minimum similarity as the heap fills, so a row that cannot reach what the heap already holds is rejected before anything is made for it. The dense path never adopted that.

DotProductRows.addRows now raises its minimum through ResultHeaps.tightenedMinSimilarity() after every row it adds, which is the same helper and the same conservative bound the scan uses, one step below the weakest row kept. A row tying with the weakest is therefore still offered to the heap rather than skipped, so what a query returns is unchanged.

Measured on a devpod at 200k rows of 512 dimensions, k of 100, 24 threads, one dispatcher, selecting the true best rows with no minimum similarity: 268 queries a second against 203 at one query a batch, and 744 against 449 at 113. Selection fell from 83% of a query to 72%.

Three tests cover it: the best rows are kept, rows tying with the weakest still fill the bound, and a query's own minimum still excludes what is below it.

658 tests pass.