Fix off-by-range bug when filter applied to table

[tomk-amd]

Motivation

Fix FILTER dropping leftover merged-table rows when the row count is not divisible by the worker count.

Technical Details

A filter that selects all event can lose result rows:

vs no filter:

AI Analysis

This one is a real off-by-range bug. It is just easy to miss on a small table.
The FILTER worker is written as a half-open index range: evaluate rows [start_row, end_row).

rocprofvis_db_table_processor.cpp Ln 603–606:

auto task = [&](size_t start_row, size_t end_row, std::exception_ptr& eptr) {
    // ...
    for (size_t row_index = start_row; row_index < end_row; row_index++)

The main threads pass that correctly: thread i gets [i * rows_per_task, (i + 1) * rows_per_task).
Integer division usually leaves a remainder, so they spawn one more thread for the leftover rows:

rocprofvis_db_table_processor.cpp Ln 630–635:

size_t rows_per_task = thread_count == 0 ? 0 : m_merged_table.RowCount() / thread_count;
size_t leftover_rows_count = m_merged_table.RowCount() - (rows_per_task * thread_count);
for (int i = 0; i < thread_count; ++i)
    threads.emplace_back(task, rows_per_task * i, rows_per_task * (i + 1), std::ref(eptr));
if (leftover_rows_count > 0)
    threads.emplace_back(task, rows_per_task * thread_count, leftover_rows_count, std::ref(eptr));

The last call mixes two conventions. The first argument is a start index. The second is still named end_row in the lambda, but they pass leftover_rows_count, which is a count (typically 1..thread_count-1), not an exclusive end index.

Concrete numbers: 10001 rows, 2 threads (this is the first size where a leftover thread exists; see below).

rows_per_task = 10001 / 2 = 5000
leftover_rows_count = 1
Thread 0: [0, 5000)
Thread 1: [5000, 10000)
Leftover thread: start_row = 10000, end_row = 1
The loop is for (row_index = 10000; row_index < 1; ...). It never runs. Row 10000 is never evaluated, so it never enters m_filter_lookup.

The filtered table size is m_filter_lookup.size(). That last row is treated as a non-match even if it would have passed. You lose at most thread_count - 1 trailing rows, not a random scatter through the table.

The GROUP path next door does the end bound correctly: its last thread gets RowCount() as end_row. FILTER should do the same (start + leftover, or just RowCount()).

Test Plan

Verify no filter and filter that would select all rows return the same count