Follow-up: make WORK_LIMIT handling consistent in strong branching pseudo-costs

[coderabbitai]

Summary

There is a pre-existing inconsistency in cpp/src/branch_and_bound/pseudo_costs.cpp around how dual_status_t::WORK_LIMIT is handled in strong-branching and reliability-branching code paths.

Today, some merge/validation logic treats WORK_LIMIT as a usable Dual Simplex outcome, but the corresponding objective-computation paths do not consistently compute and propagate an objective for that status. That can lead to a WORK_LIMIT result being selected as a Dual Simplex contribution while still carrying a NaN objective, which then prevents the expected pseudo-cost update.

Why this matters

Strong branching and reliability branching rely on consistent status/objective handling to produce valid pseudo-cost updates and branch scoring. If WORK_LIMIT is considered a valid partial result, the code should compute and carry the corresponding objective everywhere that status is accepted.

Affected area

• cpp/src/branch_and_bound/pseudo_costs.cpp

Relevant logic includes:

• is_dual_simplex_done(...)
• strong branching result handling in strong_branch_helper(...)
• trial branching result handling in trial_branching(...)
• merge logic in merge_sb_result(...)

Requested follow-up

Make WORK_LIMIT handling consistent across all Dual Simplex strong-branching paths in cpp/src/branch_and_bound/pseudo_costs.cpp.

Specifically:

• If WORK_LIMIT is intended to be a usable Dual Simplex result, include it everywhere the code currently accepts other usable partial outcomes such as ITERATION_LIMIT and CUTOFF.
• Ensure the objective value is computed and propagated for WORK_LIMIT in the same places where that status is considered mergeable/consumable.
• Verify that the resulting pseudo-cost update paths no longer silently skip valid WORK_LIMIT outcomes due to NaN objectives.

Acceptance criteria

• WORK_LIMIT is handled consistently in status validation, objective computation, and merge logic for the affected strong-branching code paths.
• No path can merge/select a Dual Simplex WORK_LIMIT result while leaving its objective as NaN.
• The follow-up is handled separately from PR Refactor: mathematical_optimization namespace #1446 because this is a pre-existing issue.

Backlinks

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

Requested by @mlubin.