fix(expr): fix memory accounting gaps in coercion, attributes, and slices

[mwiebe]

What was the problem/requirement? (What/Why)

The expression evaluator in openjd-expr enforces a memory limit so that an expression like 'A' * 100000000 fails instead of exhausting the host. It does this with a running total: each value's size is added when the value is created and subtracted when it is consumed. That total is only useful if both sides agree on every value's size and every allocation goes through it.

Four places did not meet that bar:

1. Type coercion. When a value is coerced to a target type after being created (an int to a string, or a range_expr to a list[int]), it was added at the old size and later subtracted at the new size. For growing coercions this subtracted too much, hiding memory that was still in use. A range_expr coerced to a list was never checked against the limit at all.
2. Friendly error messages. Attribute access (x.name) and method calls replace low-level errors with clearer ones like "Undefined variable" or "'name' is a property, not a method". A memory- or operation-limit error went through the same replacement and came out as an ordinary error. The evaluator deliberately ignores ordinary errors in some places (an if/else whose condition is not yet known evaluates both branches and tolerates one failing), so a limit error could be silently dropped.
3. Slice bounds. For x[:], the omitted bounds were passed along as placeholder values that were never added to the total but were subtracted from it afterwards, 64 bytes each.
4. String slicing. slice_string built two temporary vectors (4 bytes per input character, 8 bytes per selected character) that were never counted or checked, then built a result whose buffer capacity had grown past its actual length.

What was the solution? (How)

• eval_node releases the original value, coerces it, and tracks the coerced value.
• eval_attribute and eval_call check whether an error is a limit error before replacing it, and pass limit errors through unchanged.
• Slice placeholders are tracked when created. The two early exits for an unresolved receiver or bound also release the operands they discard.
• slice_string computes the number of selected characters arithmetically, checks min(input bytes, 4 × count) against the limit before allocating, copies the characters straight from the input with no temporaries, and shrinks the result buffer so its tracked size is exact. slice_list gets the same pre-check. While testing this, the shared index loop was found to overflow on a step near i64::MAX (a debug-build panic on 'hello'[1::9223372036854775807]); it now saturates.

What is the impact of this change?

The memory limit is enforced more accurately. Expressions that grow a value through coercion, or that slice large strings, can now hit the limit where before they slipped under it. Limit errors can no longer be hidden by a friendlier error message. The peak_memory metric reported by evaluate_with_metrics changes for affected expressions.

Value semantics do not change. The only user-visible message changes are byte counts in memory-limit diagnostics; one existing pinned figure moves by 128 bytes.

How was this change tested?

• Have you run the unit tests? Yes: cargo test --workspace, plus cargo clippy --all-features --all-targets --workspace -- -D warnings and cargo fmt --all -- --check.
• 15 new tests. Each fix has at least one test that fails when only that fix is reverted, verified by reverting each hunk individually. Byte figures in the new tests were derived by hand from size_of::<ExprValue>() and the heap-size rules and match the output exactly.
• An independent review of the change re-derived the figures and confirmed the per-hunk test isolation. It found the eval_call case (fix 2), which was added as a result.

Was this change documented?

• Are relevant docstrings in the code base updated? Yes. specs/expr/evaluator.md (Target Type Propagation, Attribute, Call, Speculative evaluation, Subscript) and specs/expr/function-library.md (Preflighting Output Budgets) describe the new behavior.

Is this a breaking change?

No. No public signatures change. Expressions that previously passed a memory limit only because of an accounting error may now fail it; that is the limit working as intended.

Does this change impact security?

This change tightens the memory bound the evaluator enforces on untrusted template expressions. It does not create or modify files and does not need threat modeling.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.