Compute trellis transcendentals with libm so the bitwise snapshot holds on every platform

[ciaranra]

Problem

The dev Rust lane has been red on macOS and Windows since #504 merged: decode_outputs_match_bitwise_snapshot pins raw f64 bit patterns, but the committed snapshot was generated on Linux. The platform math libraries round ln/exp/ln_1p differently by one ULP, so two random_seed23 scenarios diverged in their log_evidence/log_mass bits on the other platforms. PR CI runs the test matrix on ubuntu only, which is how the mismatch reached dev unseen.

Fix

Route the trellis engine's transcendentals (log_odds, suffix-compatibility log-probabilities, bp_score_probability, logaddexp) through the libm crate, which is pure Rust and returns identical bits on every platform. This follows the precedent already set in pecos-num::special, which uses libm::lgamma for the same reason. The committed snapshot is regenerated once against the libm values.

The brute-force enumeration oracle in the trellis tests deliberately stays on std math: it is tolerance-compared, and an independent oracle is more useful when it does not share the engine's implementation.

Verification

• Snapshot diff audited: 72 changed lines, all of them log_evidence/log_mass hex values; every predicted label is unchanged, so decode decisions are identical before and after.
• The snapshot test demonstrably fails when engine bits change (it did against the pre-regeneration snapshot) and passes after regeneration.
• cargo fmt --check, cold cargo clippy --locked --workspace --all-targets -- -D warnings, and the full pecos-trellis + pecos-frontier test suites are green.
• Because PR CI is ubuntu-only, the full three-OS matrix was dispatched on this branch via workflow_dispatch to prove the fix cross-platform before merge; see the linked run on the branch.