STRING-INDEX-0: carry ASCII-ness on RcStr so char_at is O(1)

[gunbai-bot]

Summary

Value::Str now wraps RcStr { rc: Rc<str>, is_ascii: bool }, computing is_ascii once at construction (DESIGN §5 construction-over-validation) instead of rescanning the whole string on every char_at/substring/string_length call. That per-call s.is_ascii() rescan was the O(n) cost hiding inside what looked like an O(1) accessor, turning repeated indexing over a large string into O(n^2) (STRING-INDEX-0). This supersedes the pointer-keyed ASCII cache withdrawn in CHARAT-0 (#8320) for aliasing on allocation reuse.

v1_rt.rs's char_at/substring/string_length gain _ascii_aware variants taking the precomputed flag; all interpreter call sites in v1_interpreter.rs route through them via RcStr::is_ascii(). RcStr::ptr_eq preserves pointer-identity semantics for consumers that need it (e.g. the value_str_rc_semantic_parity sharing control from #8306).

Two small consumer adaptations follow from Value::Str now wrapping RcStr instead of a bare Rc<str>: derived_realization_schedule.rs uses s.rc() to get an owned Rc<str>, and recorded_fixture.rs uses s.as_ref() for JSON serialization.

Evidence

• char_at_unicode_witness_test.dag (green): ASCII and non-ASCII behavior parity, unchanged semantics.
• value_str_rc_semantic_parity_tests::*ptr_eq* (green, from STR-RC-0: share Value::Str storage to eliminate recursive deep-copy memory blowup #8306): Rc sharing semantics preserved across the RcStr wrap.
• New isolated char_at_scaling_probe (not floor-enrolled, scaffold with a declared dissolution trigger, same class as the existing json_parse_scaling_probe): a single char_at call through the interpreter, repeated at varying position and varying string length, with no JSON parsing or list accumulation in the loop — isolating exactly the one thing this PR changed. Remote receipt (exit 0): mean per-call cost flat at ~3.3–3.8µs across string lengths 10K–2M chars (200x range) and positions spanning 0–99% of each length, with no growth trend against either axis. This is the char_at-specific O(1) evidence.

Scope note: JSON end-to-end scaling is unchanged, and that's expected

The existing json_parse_scaling_probe.rs's end-to-end parse scaling exponent (~2.06, measured pre-PR) is unchanged by this PR. That's not a regression — the JSON parser's dominant cost is a different, pre-existing defect in the List carrier's accumulation path, out of this PR's scope.

This PR adds a counters mode to that probe, reporting MutationCounters (list_push_calls vs list_push_items_copied) around a parse. Result at 20KB/40KB/80KB (2048/4096/8192 members): list_push_items_copied = 0 at every size while list_push_calls scales linearly with member count. This refutes the initial hypothesis that the exponent was caused by value_to_list_carrier's free_monoid_to_vec O(m) fallback-copy branch on the push path (that branch is never taken here — the accumulator arrives as a native Value::List on every push, hitting the cheap 0-copy path).

Update: the root cause is no longer open — it is diagnosed, with a successor named. native_len (v1_interpreter.rs), which backs method_call.length/method_call.is_empty (x.length(), x.is_empty()), has no Value::Str arm — verified directly in this PR's branch — so a .length()/.is_empty() call on a string falls through to free_monoid_to_vec, which materializes the entire string into a Vec<Value> of chars just to report its count: an O(n) full-string flatten hidden behind what reads as an O(1) accessor, the same failure shape STRING-INDEX-0 fixed for char_at/substring/string_length, on a sibling call site. This was independently identified by bright-otter-592 and is out of this PR's scope: it lives in native_len's dispatch, adjacent to but not inside the List-carrier machinery (list_push, value_to_list_carrier, free_monoid_to_vec) this PR is scoped away from touching. list_push, value_to_list_carrier, and free_monoid_to_vec remain untouched in this PR; the fix belongs to a successor work item (adding a Value::Str arm to native_len).

The cold 507KB parse and the two Codex-materialization measurements from this work item's original brief are deferred to a future joint receipt once that List-side defect is diagnosed, per explicit scope guidance from the parent session.

Test plan

• char_at_unicode_witness_test.dag — green (Unicode/ASCII char_at parity witness).
• value_str_rc_semantic_parity_tests (cargo test, #8306) — green (Rc sharing/ptr_eq controls).
• char_at_scaling_probe (new, not floor-enrolled scaffold) — remote run, exit 0, flat ~3.3–3.8µs/call across a 200x length range and full position range: the O(1) receipt for this change.
• json_parse_scaling_probe --mode counters (new mode on existing scaffold) — remote run, exit 0, list_push_items_copied = 0 at all three tested sizes: refutes the free-monoid hypothesis for the (unchanged, out-of-scope) JSON end-to-end exponent.

Closes dashboard://work-items/adhoc-c6d0ad7b-28b