2026-09-01 - (/loop) The call trace records what each call answered

The user asked to focus on the watchpoint feature and crack the refers, and - reading the last fault report - whether we really had to walk backwards up the call chain, and whether there was any baseline to check against. Reading the dispatch path answered both: every recording captured what the guest passed in and nothing captured what our function handed back, so the wrong return - the thing at both of PPSA02664's walls - was structurally invisible, and the "baseline" is our own graded oracle (FreeBSD source, the guest as a 1-bit oracle, obSCEne on hardware), already used in this codebase (the flexible-memory figure in orbistoun-kernel, D444).

So rather than walk backwards by hand, made the record complete. on_guest_call now stores the answer in two allocation-free rings beside the argument (RING_RET + a Release flag RING_RETURNED, because zero is OK and must not read as "not seen"), funnelling the four return paths through one resolve helper so none can forget to record. RecordedCall.ret / TracedCall.returned are Option<u64>; the report prints -> 0xNN on the tail and the "just before" lines when known. Recorded D459. cargo test green (report 68, thunk 26, +3 new round-trip tests pinning zero-survives, unknown-is-absent, and older-trace-loads); fmt clean; clippy adds no new warnings (the two it reports - enter too_many_lines and a sha256 map/ unwrap_or in the CLI - are pre-existing debt, untouched here).

The surprise is the payoff. On PPSA02664 the return column named both non-deterministic walls (D450) at a glance:

Next, as two separate units, each verified by whether the wall moves rather than by looking right: (1) make map_named_direct_memory commit into an existing reservation instead of reserving afresh; (2) implement _Getpctype to answer a real ctype table - taking the layout from an oracle first, and noting that the earlier revert of a _Getpctype attempt was driven by the D450 non-determinism read as a regression, not by a real one.