Possible race: RINS worker incumbent size can mismatch leaf_problem.num_cols in branch_and_bound.cpp

Surfaced by draft PR #1905 (compiling against a different OpenMP runtime, which shifts B&B task-scheduling timing). CI hit a native assertion abort:

```
branch_and_bound.cpp:3066: Assertion `worker->current_incumbent.size() == worker->leaf_problem.num_cols' failed.
Fatal Python error: Aborted
```
in `tests/linear_programming/test_incumbent_callbacks.py::test_incumbent_get_set_callback[/mip/neos5-free-bound.mps]`. A separate CI run on the same branch also saw `test_mip_incumbent_stream` time out, which may be the same underlying issue.

Where

```cpp
if (use_rins) {
mutex_upper_.lock();
worker->current_incumbent = incumbent_.x;
mutex_upper_.unlock();
assert(worker->current_incumbent.size() == worker->leaf_problem.num_cols);
}
```
(cpp/src/branch_and_bound/branch_and_bound.cpp, around line 3062-3066)

`incumbent_.x` is copied under `mutex_upper_`, so the copy itself isn't torn — but nothing guarantees `incumbent_.x`'s dimensionality matches this worker's `leaf_problem.num_cols` at the moment of the check. Since #1543 already documents this same test as timing-sensitive (`test_incumbent_get_set_callback[swath1.mps]` failing with TimeLimit on oldest-deps), this looks like a pre-existing race whose trigger probability is just sensitive to B&B/OpenMP scheduling timing, not something introduced by #1905 itself — worth confirming whether it reproduces on main with enough repetitions, and whether `leaf_problem` can legitimately have a different column count than the global incumbent (presolve column elimination in submip construction?).

Related: #1543, #1774 (a previous concurrent-access race in `clique_table_` with the same "scheduling-timing-dependent" shape).