fix(profile): stop MaddisonSlatkin profile scoring hanging on macOS (arm64)

[ms609]

Problem

R CMD check --run-donttest hangs for 6 hours (the GitHub ceiling) on macOS, intermittently taking the ubuntu R 4.1 leg instead. The hang is in checking examples with --run-donttest, on the pre-existing TreeLength(..., concavity = "profile") example in tree_length.R (dataset inapplicable.phyData[[1]] = Agnarsson2004, 62 tips).

Root cause

PrepareDataProfile() → StepInformation() runs the exact MaddisonSlatkin recursion for 3–5 token characters. Its memoization uses fixed-capacity open-addressing maps (OAFlatMap: logB_cache, logPVec_idx) reserved on the assumption that a character never needs more entries than reserved.

A skewed 3-state character has a low split-count, so the feasibility gate classes it feasible for the exact solver — but on many tips it generates far more distinct (token, leaves) keys than reserved. Agnarsson2004 column 83 is [42, 9, 2]: ~9000 keys vs logPVec_idx's 4096-entry reserve. Once the table fills, probe_slot() — which stops only on an empty slot — loops forever, and that loop lives outside LogB/LogPVec, so the existing 2-second wall-clock budget cannot interrupt it.

It's a race the platform decides:

• x86-64 (windows, ubuntu): the 2 s budget usually fires first → returns NA → the R caller falls back to the Monte Carlo approximation → completes. The blowup is invisible.
• Apple Silicon (arm64): the table fills before 2 s elapses → infinite probe_slot → hang.

This is pre-existing and independent of any feature work; it surfaced as a CI timeout because the profile example exercises exactly such a character.

Fix

Add OAFlatMap::at_capacity() (true at load factor 0.5 — the reserved size) and, alongside the existing time-budget guard in LogB()/LogPVec(), bail to the NA → Monte-Carlo fallback the instant a memo table reaches its reserved capacity.

Bailing at the reserve keeps entries_ within its reserved storage, so the table can neither fill (no probe_slot infinite loop) nor reallocate (which would also have dangled the FixedProbList* held across recursion) — fixing both the hang and a latent dangling-pointer UB in the same blowup case. Characters within reserve are unaffected (exact result unchanged); over-reserve characters were already broken (UB/hang) and now return the correct MC approximation.

Verification

• macOS arm64 (the platform that hung): the [42, 9, 2] character now completes in 0.91 s (was a 6 h hang) with the capacity warning; full profile TreeLength(Agnarsson2004) completes in 14 s. Confirmed green on macOS-latest, ubuntu-24.04 (R 4.1) and windows-latest.
• x86-64: all profile/parsimony tests pass (MaddisonSlatkin 56, pp-info 131, ts-profile 43, tree_length 75, iw-profile 15 — 0 failures), including a new regression test asserting the overflowing character falls back instead of hanging.

🤖 Generated with Claude Code