test(core): de-flake message_features (core_message_bdd) — concurrent ask/tell race

[joeldsouzax]

The message_features runner (tests/core_message_bdd.rs) has a flaky scenario:
the concurrent ask/tell property — "When concurrent tasks send a mix of asks and tells" →
"the final state equals the deterministic result of applying every command once" /
"no command is lost or applied twice".

Symptom: passes ~13/14, fails ~1/14 (panic in cucumber-0.23 cucumber.rs:1243, "1 step failed").

Where it bites:

• Reddens the Coverage workflow on main (release build) — its last 2 runs failed on exactly this (test(console): cover tui::App render branches + poller loop orchestration (#82) #99, test(console): PTY-driven E2E smoke test for main.rs + input poll (#83) #101 merges).
• Latent risk to the now-required Nix Flake Check status gate (ruleset #18433270): a flaky nextest run can block a legitimate merge. It happened to pass on chore(ci): repo hardening to cesr parity — spell-check + nix hygiene gates #105, but it's a coin-flip.

Likely root cause: the test asserts final state before all spawned tasks have settled — a classic concurrency snapshot-timing bug (assert fires a hair early), not a bug in the SUT.

Fix (de-flake, don't loosen the assertion):

• Ensure real overlap with a tokio::sync::Barrier, then await every spawned task/join handle before snapshotting state (per CLAUDE.md test-quality rule 8: "concurrent tests use real overlap … not sequential-then-check").
• Keep the assertion exact (deterministic fold of all commands), just move it after the join.

Sibling of the supervision de-flake #100. Surfaced during card #104 (repo hardening / clippy-gate parking).

[joeldsouzax]

Correction from investigation (PR #108): the flaky step is not the concurrent ask/tell scenario named above, but "ctx.reply sends an early reply and returns a DelegatedReply marker" → "no duplicate reply is sent when the handler returns".

CI evidence (coverage runs on #99/#101):

✘ And no duplicate reply is sent when the handler returns
  Step panicked: the handler must have continued working after the early reply, log=[]

EarlyReply::handle calls ctx.reply(13) (resolving the caller's ask().await immediately), then does its post-reply log.push(13). The step asserted log.contains(&13) before the handler's continuation ran — a race lost under CI contention (2-core + llvm-cov), giving log=[].

The "assert fires too early" hypothesis was correct; the scenario pointer was not. The concurrent ask/tell scenario already awaits all join handles behind a Barrier and is deterministic (held green across 192 contended + 2000 starved local runs) — no change needed there.

Fix keeps the exact assertion and adds a single-writer settle barrier (a follow-up ask the actor can only process after the EarlyReply handler returns). Reproduced deterministically on a 1-worker runtime before fixing.