Two small post-PR-#631 cleanups, both surfaced during that PR's
review:

- **#633** — `_resolve_base_type_name` in `vera/wasm/inference.py`
  now carries an explicit `_seen` cycle-detection accumulator,
  restoring consistency with the sibling `_canonical_named_type`
  walker that already had one.  Defence-in-depth: cyclic type
  aliases are user errors that should be rejected upfront by the
  type checker (filed as #648 — the upstream `RecursionError`
  observed while validating #633's reachability), but a bug in
  the upstream rejection must not turn into a stack-blow inside
  codegen.  New unit test exercises the guard directly via
  injected cyclic `_type_aliases` (two-, three-, and self-cycle
  cases).

- **#634** — `SlotRef` and other AST nodes constructed inside
  `InterpolatedString.parts` now carry source spans in
  original-source coordinates instead of synthetic-wrapper
  coordinates.  `_parse_interp_expr` previously wrapped each
  segment in a dummy `fn interpExpr() { <SEG> }` for parsing,
  placing the segment at wrapper line 3, col 3 — and Lark spans
  emitted inside the parsed body were never translated back, so
  diagnostics on interpolated expressions landed on line 3 of
  the user's file regardless of where the string literal actually
  was.  `_split_interpolation` now records each segment's offset
  within the raw string; `string_lit` computes the segment's
  original line/column from the outer string-literal span; and
  `_parse_interp_expr` walks the parsed AST and remaps every
  `Span` via a new `_remap_spans_inplace` helper (uses
  `object.__setattr__` to bypass frozen-dataclass guard — safe
  because `Node.span` is declared with `compare=False` precisely
  to allow this kind of late correction).

  The softened assertion in
  `TestE615LoudInterpolationFallthrough630::test_e615_fires_on_adt_in_interpolation`
  is tightened to pin both line (8) **and** column (15) of the
  diagnostic at the SlotRef's position, and
  `test_multiple_e615_in_one_interpolation` now pins per-segment
  column fidelity — two SlotRefs in the same string get two
  distinct columns (15 and 37) matching their actual source
  positions.

KNOWN_ISSUES.md: removed entries for #633 and #634; added
entry for #648.

Closes #633.
Closes #634.

Co-Authored-By: Claude <noreply@anthropic.invalid>

PR #649's CI lint step (`ruff check --select S vera/`) flagged two
S101 violations on the new `assert isinstance(segment, ...)` calls
in `string_lit`.  S101 is the right call here — `assert` statements
are stripped under `python -O`, so they shouldn't be load-bearing
in production code, even when their primary purpose is mypy
narrowing.

Refactored to isinstance-based dispatch, which provides both the
mypy narrowing and runtime safety without the assert.  The
alternating-layout contract of `_split_interpolation` is now
enforced by the if/else structure rather than asserted, which is
the more honest expression of the invariant.

Co-Authored-By: Claude <noreply@anthropic.invalid>

Two more Tier A items in today's bug burn-down (following #633 + #634
in the previous commits on this branch):

- **#556** — calling a user-defined `@Unit`-returning function in
  statement position used to fail WASM validation
  (`type mismatch: expected a type but nothing on stack`).  The
  bug class was already fixed by #584 in v0.0.135 (the
  `_is_void_expr` registry update in `vera/wasm/context.py`).
  The original #556 report's *exact* repro shape — a pure helper
  (no IO effect) followed by a unit-literal final expression —
  wasn't pinned by the existing conformance test
  `ch07_unit_fn_nontail.vera` (which covered IO-effect variants
  only).  Added `TestUserUnitFnInStatementPosition556` with two
  regression cases (the pure-helper variant and the where-block
  variant from the follow-up comment).

- **#591** — three network-response UTF-8 decode sites in
  `vera/codegen/api.py` no longer leak Python
  `UnicodeDecodeError` text into Vera-level `Result::Err`
  strings.  Two strategies, chosen per-site by user intent:

  - **`Http.get` / `Http.post`** (lines 2826, 2858) — switched to
    `errors="replace"`.  A remote server returning non-UTF-8
    bytes surfaces as U+FFFD substitutions in the Ok-branch
    string, preserving the data.  User intent for these calls
    is "fetch this URL"; preserving the body beats preserving
    the (already-rare) signal that bytes weren't cleanly UTF-8.

  - **`Inference.complete`** (line 756, in
    `_call_inference_provider`) — now catches `UnicodeDecodeError`
    explicitly and re-raises as `RuntimeError("Inference
    provider '<name>' returned a response body that is not
    valid UTF-8 (invalid byte at position N).")`.  The
    `host_inference_complete` wrapper's existing
    `except Exception` catches this and writes the
    Vera-shaped message into the Err branch.  Non-UTF-8 from
    an LLM API is genuinely broken; we want loud failure with
    a Vera-native message, not the `codec can't decode byte
    0x...` Python form.

  Three structural assertions in
  `tests/test_runtime_traps.py::TestNetworkResponseUtf8Hygiene591`,
  mirroring the #589 coverage shape.

KNOWN_ISSUES.md: removed entry for #591.
TESTING.md, ROADMAP.md: test counts refreshed (3,797 → 3,802).

Closes #556.
Closes #591.

Co-Authored-By: Claude <noreply@anthropic.invalid>

Two valid findings, both fixed with new regression coverage:

**Finding 1 — `_resolve_base_type_name` returned the revisited
cycle node, not the caller's original name, on prefix-chain
cycles.**

For aliases `{A: B, B: C, C: B}` (A leads INTO a B↔C cycle that
doesn't include A itself), calling with `A` previously returned
`B` (the revisited cycle node where `name in _seen` first hit),
not `A` (the caller's input).  My initial test only covered FULL
cycles (`A→B→A`, `A→B→C→A`, `X→X`) where caller-name == revisited-
name by definition, hiding the bug.

Fix: thread a `_root_name` parameter through the recursion (set
to the original `name` on first call, preserved across recursion).
The cycle guard now returns `_root_name`, so the function's
identity-on-cycle contract is "return what you were asked about,
unchanged".

Added a regression test case covering the prefix-chain shape:
`_resolve_base_type_name("A")` with `{A: B, B: C, C: B}` must
return `"A"`, not `"B"`.

**Finding 2 — `_split_interpolation` mis-segmented escaped
backslashes.**

`_has_interpolation` correctly skipped escaped pairs (so a string
like `"\\("` was seen as having no interpolation at all), but
`_split_interpolation` rescanned the second character as a fresh
start and mis-parsed the `\\(` as the opener of an interpolation
segment.  Result for `"a\\(b)c"`: a parse-time crash (no matching
`)`) where the user expected a literal `a\(b)c`.

Pre-existing bug (not introduced by this PR), but CodeRabbit
flagged it because PR #649 touches the function.  Fixed
opportunistically since the scope is small and the
two-helpers-must-agree invariant is exactly what the file already
encodes.

Fix: aligned `_split_interpolation`'s escape-skipping with
`_has_interpolation`'s shape — when a `\` is followed by any
character other than `(`, both characters are appended to the
literal buffer and `i` advances by 2 so the escaped character is
not re-scanned as a potential interpolation opener.

Added `test_escaped_backslash_before_paren_is_literal` to
`TestStringInterpolation` exercising the `"a\\(b)c"` case
end-to-end.

Doc counts refreshed (3,802 → 3,803).

Co-Authored-By: Claude <noreply@anthropic.invalid>

CodeRabbit-flagged: the previous assertions in
`TestNetworkResponseUtf8Hygiene591::test_http_post_uses_errors_replace`
checked the bare substring `'errors="replace"'`, which also
appears in the explanatory comment block immediately above the
real decode call.  A future regression that removed
`errors="replace"` from the actual decode while leaving the
comment intact would pass the test spuriously.

`test_inference_complete_catches_unicode_decode_error` wasn't
vulnerable in current code (the production `except` keyword does
not appear in nearby comments — they use backtick-quoted
`` `UnicodeDecodeError` ``) but a future comment containing the
literal substring `except UnicodeDecodeError` would break it.

Both tests now use `re.search` with patterns that bind the target
phrase to the surrounding code expression:

- **http_post**: the regex
  `r'resp\.read\(\)\.decode\([^)]*errors="replace"'` requires
  `errors="replace"` to be part of the same `resp.read().decode(...)`
  call.  `[^)]*` permits the multi-line form (with `"utf-8",`
  argument on its own line) while forbidding any closing paren
  between `decode(` and `errors="replace"` — so a comment placed
  outside the call cannot satisfy the match.

- **inference**: two regexes, one for the contiguous
  `except UnicodeDecodeError ... raise RuntimeError(` block
  (up to 10 lines between to allow whitespace and the `from None`
  trailer), one for the `not valid UTF-8` phrase inside the
  `raise RuntimeError(...)` argument string.  The DOTALL-flag
  bounded `.{0,400}?` permits adjacent-literal f-string
  concatenation across multiple lines (the production code
  splits the message across three `f"..."` for readability).

Validated the regexes reject the comment-only-stub failure mode
with a direct counter-example test (substituted a body where
`errors="replace"` lives only in a comment and the decode is
strict-mode; regex correctly returned None).

Added `import re` to the test module's imports.

Co-Authored-By: Claude <noreply@anthropic.invalid>