t27b: specs/tri/crypto/crypto.t27 went from blocked to fail after #8696 unblocked std.mem.Allocator #8717

Seen in the post-merge receipt compare for the network MVP v2 (#8685): the only regression in the pair is specs/tri/crypto/crypto.t27, blocked -> fail. It comes from #8696 ('carry a std.mem.Allocator that is never called', see #7917), not from the MVP PR.

Before #8696, t27b refused the spec at the Allocator construct. Now it compiles it, and at least one test fails. Either t27b miscompiles something later in the spec, or a runtime assert disagrees with the reference.

To do: on the t27c lab, run t27b test specs/tri/crypto/crypto.t27 --check against t27c test-report, find the first failing test and its first disagreeing assert, and fix t27b (net <= 0 hand lines under cli/t27b, #8236).

The ledger steward refuses to apply this by itself (MOVED / UNEXPECTED_FAILURE), and that is correct: a lane must look.

User Scenarios

• Given t27b previously blocked on specs/tri/crypto/crypto.t27 due to std.mem.Allocator, when t27b: carry a std.mem.Allocator that is never called (Closes #7917) #8696 unblocks Allocator, then t27b compiles the spec but at least one test fails with a disagreeing assert against the t27c reference.

Requirements

• FR-001: t27b MUST compile specs/tri/crypto/crypto.t27 without internal error after Allocator unblocking.
• FR-002: t27b MUST produce test results that agree with t27c test-report for the first failing test and its first disagreeing assert.
• FR-003: The fix MUST be contained within the t27b compiler implementation (net ≤ 0 hand lines).

Success Criteria

• t27b test specs/tri/crypto/crypto.t27 --check exits with exit 0 and zero disagreeing asserts against t27c test-report.
• The first previously failing test in specs/tri/crypto/crypto.t27 passes with matching asserts.

Boundary

• specs/tri/crypto/crypto.t27
• scripts/tri_loop/t27b.py
• .trinity/queue/blocked.json