state_exec: max_memory counts the deep-data work a process waits on

[transfix]

Stacked on #689. Review the last commit, 26e0bf3. It targets master so CI runs; once #689 merges, master gets merged in here.

Why

max_memory covers a process's measured heap (#667), but a measurement could not start while the process waited on deep-data work, and it never looked at what that work held. A process that never stops waiting was held only by max_steps/max_time. Two cases:

• a class whose init is its own constructor, (begin (defclass P) (set-attr P.__cls_dict__ "init" P) (P)), which after state_exec: native calls past the first level are the evaluator's #689 is a loop of steps instead of a nesting error. Each level passes init one argument more, so memory grows quadratically;
• a closure init that constructs again, (begin (defclass P (init (self) (P))) (P)). Master has this one too.

What changed

• Jobs report what they hold. data_job has two new virtuals:
  • held_values(visit) visits the values a job owns copies of;
  • held_bytes() gives the job's own size and buffers.
  • The call job (call_walk: function, arguments, result) and the generator job (collect's gathered values) implement them. The stdlib jobs only borrow their caller's arguments or build results held to the allocation limit, so they don't need to.
• A job left to run after its call reports its bytes (eval_alloc_note in run_data_job), so a re-measure comes due as waiting calls pile up.
• A measurement can start on top of work in flight. heap_after_step now starts a measurement during a call in flight: innermost, with outer set and waiting on no frame. It runs first, and the call goes on after it. heap_share_job counts each pending work and what its job holds.
• fork refuses whenever a frame waits on data work anywhere in the chain (waits_on_data_work), not only when that work is innermost. So a fork during a measurement that runs on top of a call is still refused.

Measured

Each runaway, with max_memory = 2 MiB and no other limit hit (MSVC Release):

Script	killed at step	measurements	measured heap
constructor that is its own init	138	8	2.12 MB
closure init that constructs again	5424	4	2.12 MB

Before this change, neither was ever measured: the first ran into max_steps with a quadratically growing argument chain, the second until max_steps/max_time.

Tests

state_exec_heap_test:

• AMeasurementRunsOnTopOfACallInFlight: a measurement due while collections.map calls a lambda sits on top of the map's work, runs without stepping any frame, and then the map finishes with the right result. waits_on_data_work holds meanwhile, so no fork.
• TheWorkAProcessWaitsOnCounts: after 100 steps of the self-init runaway, the measured share includes the waiting calls' arguments (over 10000 values).
• ACallChainThatNeverEndsRunsOutOfMemory: both scripts, on the async scheduler (exit error memory_limit_exceeded) and the sync one (killed before the step backstop, measured heap at least the budget).

Docs: the developer guide's "Memory: state-tree writes and the measured heap", "Native call nesting" in docs/STATE_EXEC_GRAMMAR.md, and the pycvc parity table (waits_on_data_work is internal).

Local results (MSVC 14.38 Release, Windows, cvcpkg prefix)

• All 78 state_exec, Ariadne, state and app suites pass (2355 tests), 6 at a time, with no failures.
• state_exec_deep_data_test passes at 64 KiB.
• clang-format 18 is clean on the changed lines.
• NativeCallThroughput and EvalFibonacci are within noise of state_exec: native calls past the first level are the evaluator's #689.