Track inconsistent WORK_LIMIT handling in dual-simplex strong branching

[coderabbitai]

Summary
cpp/src/branch_and_bound/pseudo_costs.cpp handles simplex::dual_status_t::WORK_LIMIT inconsistently in the dual-simplex strong-branching / reliability-branching paths.

Today, some merge logic treats WORK_LIMIT as a usable dual-simplex result, but other status checks and objective-computation paths do not consistently include it. That can leave a branch marked as solved/usable while its objective remains unset (NaN), which can in turn cause pseudo-cost updates to be skipped or merged results to be inconsistent.

Current status
This appears to be a pre-existing issue. Based on discussion in #1446, it is not currently exercised in the deterministic-mode path, but it should still be patched for correctness and consistency.

Affected areas

• cpp/src/branch_and_bound/pseudo_costs.cpp
• Status helper:
  • is_dual_simplex_done(...)
• Dual-simplex result handling in:
  • strong branching helper path
  • trial branching path
  • merge logic / result-consumption paths that already treat WORK_LIMIT as usable

Suggested fix
Make WORK_LIMIT handling consistent anywhere dual-simplex statuses are interpreted for:

• “done/usable result” checks
• objective extraction after a solve
• merge logic between dual simplex and batch PDLP

Acceptance criteria

• simplex::dual_status_t::WORK_LIMIT is handled consistently in all relevant status checks in cpp/src/branch_and_bound/pseudo_costs.cpp.
• Any code path that treats WORK_LIMIT as a usable dual-simplex result also computes/propagates a valid objective value for it.
• Strong-branching and reliability-branching flows cannot merge/select a dual-simplex result with NaN objective solely because the status was WORK_LIMIT.
• Add or update a focused regression test if there is an existing test surface for this code path.

Backlinks

• PR: Refactor: mathematical_optimization namespace #1446
• Review comment: Refactor: mathematical_optimization namespace #1446 (comment)

Requested by

• @mlubin