char_at is quadratic and unroutable: the ascii-aware repair's precomputed flag names an RcStr carrier that does not exist

[briansrls]

What

v1_rt::char_at_ascii_aware / string_length_ascii_aware / substring_ascii_aware take a precomputed is_ascii flag, and their doc comment names the producer of that flag as "the RcStr carrier fact". No RcStr exists in this tree: Value::Str is Rc<str>, and every caller — the three wrappers plus the one interpreter call site — supplies s.is_ascii(), an O(n) whole-string rescan computed fresh on every call. The split is unroutable: three public functions whose parameter has no producer, under a comment asserting a carrier that does not exist.

Provenance (the obvious reading is wrong)

Nobody deleted RcStr. b1775d8e44 (#8360) landed both halves and is not an ancestor of main. main's history is rooted at 67437fcbe9 (#8833) — a wholesale seed re-import whose tree already carries the runtime split (src/v1/runtime_rust.dag +826) beside an interpreter with zero RcStr occurrences (+16717). The flag has never had a producer anywhere in main's reachable history, and #8360's O(1) claim has never been true of this tree.

The repair

At the single authority src/v1/runtime_rust.dag; the generated mirrors follow by regen.

• Delete the _ascii_aware triplet. Nothing supplies a flag other than s.is_ascii(), so the parameter is a second representation of a fact the function can read itself (§2/§3), and the comment on it is the §4b inflation case — a carrier named for a rung the tree does not occupy.
• Bound the ASCII test by the requested index instead of by the whole string. A leading run of ASCII bytes makes the byte offset equal the code-point offset, so char_at examines bytes[..=pos] and substring examines bytes[..end], never the tail. Cost drops from O(n) + O(pos) to O(min(pos, n)) — the fallback's own cost.
• Semantics unchanged. Where the old form fell back to chars() because the string contained a multibyte char, the new form takes the byte path only when the prefix up to the requested index is ASCII — exactly the condition under which byte index equals code-point index.
• Route the interpreter's native_len Value::Str arm through v1_rt::string_length, and fix its doc comment, which named the deleted helper.
• Delete gunbc.char_at_scaling_probe_support. Its DissolutionCondition names src/v1/stage0/src/bin/char_at_scaling_probe.rs, deleted by Delete unrostered seed probes and orphan tests #9160, and its trigger is "when char_at's O(1) property is floor-enrolled" — a property this tree does not have. Unconsumed (census row in docs/plans/unconsumed-module-residue-disposition.md), subject gone.

Residual — declared, not claimed closed

A left-to-right walk of a string is still O(n²), now with a smaller constant rather than a different shape. A single call cannot be O(1) without the whole-string ASCII fact, which needs a carrier on the string value. That carrier — or a cursor surface that does not re-index from zero — is this class's next-rung trigger, and it is recorded in the char_at doc comment rather than left to be rediscovered. Re-landing the RcStr carrier is a substantial change to the v1 seed and is deliberately not folded in here.

This change lowers no rung: the deleted split was inert, so nothing it guaranteed is lost.

Test plan

Witness: dag/test/claim/char_at_unicode_witness_test.dag (SubstrateInputsOnly, floor-routed), gaining the discriminating control for the prefix-bounded path — "ab" + U+00E9 + "c" is 5 bytes and 4 code points, so a byte-offset implementation returns U+00A9 at index 3 and "c" at index 4 where code-point indexing returns "c" at 3 and "" at 4.

Run remotely (BuildBuddy), gunbc run --claim-run --function <f> per test:

function	repaired	char_at prefix check removed
char_at_indexes_code_points_on_multibyte_text	PASS	RED
char_at_byte_offset_would_mismatch_at_index_one	PASS	PASS
string_length_counts_code_points_not_bytes	PASS	PASS
char_at_agrees_across_the_ascii_prefix_boundary (new)	PASS	RED
char_at_past_the_multibyte_char_is_not_a_byte_offset (new)	PASS	RED

The perturbation binary was deleted and rebuilt from scratch, the build failure-checked rather than piped through tail, and the edit grep-proven in source, so these arms are not a stale binary answering twice.

One assertion was written and then removed — read this before assuming substring is covered

A third new assertion, substring_agrees_across_the_ascii_prefix_boundary, did not discriminate and is not in this PR. Its own perturbation — if bytes[..out_end].is_ascii() replaced by if true, taking the byte-slice path unconditionally — left it GREEN, twice, the second time under the same rebuilt-from-scratch controls. A follow-up probe that would have printed the returned values panicked in cli_run.rs on both arms, so it measured nothing; identical output across arms is the signature of an instrument that did not run, not of agreement.

It was removed rather than kept with a caveat: a check whose RED has never been observed is not coverage, and one named after the thing it does not test is worse than absent. The witness module now says so in its own note, so the disclaimer travels with the test rather than living only here.

char_at_byte_offset_would_mismatch_at_index_one (pre-existing, not authored or changed here) also fails to discriminate against this perturbation — at byte index 1 of "aéb" the byte is 0xC3, which renders 'Ã', not the '©' that assertion names.

Open question, recorded rather than routed around: substring(s, 0, 3) on "ab" + U+00E9 + "c" under the unconditional byte path slices s[0..3], which lands inside the two-byte U+00E9 and should panic on a non-char-boundary. It did not. Either that path is not reached by a named-argument .dag call, or the panic is absorbed between the interpreter arm and the claim runner's exit status. The second would be the more serious finding — a witness that cannot go red because failures are swallowed would affect every witness, not this one — and it deserves its own lane. The substring code change here stands on the semantics-preserving argument plus heavy existing corpus exercise, and explicitly not on a discriminating control of its own.

Also: cargo fmt --all --check clean; release build of the edited runtime clean.

Regen (two passes, both run)

v1_rt.rs is emitted by v1_compiler_runtime_rust.rs, which is itself the stage0 transliteration of runtime_rust.dag — so a single pass cannot converge both. Pass 1 (claim_executor --required-regen) rebuilt the mirror from the edited authority and reported first_generation_equal=false ... FAIL generated surface drift: v1_compiler_runtime_rust.rs, v1_rt.rs; that candidate mirror is installed in the second commit. Pass 2, rebuilt against it:

required-regen: first_generation_equal=true planned=135 executed=135 declared_divergent=1 [main.rs]
=== PASS2 DIFF candidate vs committed ===
SAME v1_rt.rs
SAME v1_compiler_runtime_rust.rs

Both generated mirrors are now the authority's direct, converged output — the hand-written v1_rt.rs in commit 1 is byte-identical to what the emitter produces. (declared_divergent=1 [main.rs] is pre-existing and untouched by this change.)