[0.7] Strict conformance fixtures and structured errors

[PHPCraftdream]

Goal

Move the remaining strict-mode conformance work into the 0.7 track.

Scope

• Add normative strict-mode fixtures to ktav-lang/spec.
• Define the shared expected outcomes for lossy and canonical scalar forms.
• Decide and document a structured strict-error contract, including the offending body and canonical form where applicable.
• Extend the C ABI and every binding conformance runner to consume the shared fixtures.
• Run the fixtures in CI for Rust, Python, JavaScript, Go, Java, PHP, and C#.

Context

Release 0.6.4 added parse_strict in Rust and idiomatic strict entry points in all six bindings, with binding-local regression tests. The shared fixtures were intentionally deferred because the current C ABI exposes errors as flat strings and does not yet provide a stable structured-error contract.

Definition of done

• Spec fixtures and their error expectations are normative and reviewed.
• The structured error wire/API contract is documented.
• All seven implementations pass the same strict fixture set in CI.
• README and CHANGELOG updates are synchronized in EN/RU/ZH.

[PHPCraftdream]

Decision record (2026-08-26)

Direction confirmed: one unified JSON error envelope for every structured error (parser and writer), not a distinct shape per error type.

Envelope shape

{
  "error": "UnrepresentableKey",
  "reason": "EmptyKey",
  "line": null,
  "line_text": null,
  "span": null,
  "path": ["a", "b"],
  "body": null,
  "canonical": null,
  "spec_section": "§5.9.10"
}

(that's a writer-time example — UnrepresentableKey has no source position, see below. A parse-time LossyScalar example would instead populate line/line_text/span/body/canonical and leave path/reason null.)

Field notes

• path is an array of key segments, never a joined string. A string form ("a -> b" or "a.b") has the same ambiguity problem this project just fixed for dots: a key literally named "a -> b" would be indistinguishable, as a string, from the two-segment path a → b. An array of exact segments has no separator to collide with. A display string, if a caller wants one, is a trivial path.join(\" -> \") on the consumer side — not part of the wire contract.
• line/line_text/span are populated for parse-time errors only. Writer-time errors (UnrepresentableKey) validate a Value that was never parsed from text — there is no source line to report, and inventing one would be worse than an honest null.
• Transport: the JSON envelope travels as a string through the existing C ABI error channel (out_err), not a new C struct — this avoids opening new ABI surface (lifetime/ownership questions) for what is fundamentally a data-shape problem, not a memory-layout problem.

Deliberately left to implementation, not frozen here

Per spec-driven-first ordering (normative text lands before code, per ktav-lang/spec#3's decision record), three interacting details are intentionally not decided on paper — they get resolved while implementing and the actual result is what gets documented, not a prediction of it:

1. Whether adding \uXXXX (spec#1) gives keys containing (/) an escape path, which would shrink ktav-lang/rust[0.7] Writer must reject keys it cannot round-trip #5's four refusal classes to three. \uXXXX is a new 6+ byte escape and the current raw key validator (is_valid_key in src/parser/validate.rs) assumes every escape is exactly 2 bytes — this needs an escape-aware rewrite regardless of the parens question, so the parens outcome falls out of that work rather than being decided independently.
2. span's unit of measurement. src/error/error.rs already has Span { start: u32, end: u32 } in byte offsets; LSP defaults to UTF-16 code units. Whichever is chosen must be explicit and documented — silently leaving it implicit is the same drift risk as delegating whitespace to each language's stdlib.
3. Whether the canonical writer prefers a named escape (\., \:, …) over \uXXXX when both could represent the same byte. Working hypothesis is "named escape wins, \uXXXX only when no named escape exists" (consistent with the existing ten), confirmed once implemented, not before.

Scope — full stack, not just core + six bindings

Rust core → C ABI → all six bindings (typed error/exception per language) → ktav-lsp (uses span for precise diagnostics instead of underlining the whole line) → VS Code / IntelliJ plugins (same diagnostics protocol, verify on a prototype before release) → the JS binding's WASM build → the site's playground (structured diagnostics instead of a single error-message string). tree-sitter-ktav is explicitly not wired to this envelope — it has no equivalent semantic-error class, only grammar error-nodes, and gets its own syntax-only contract (tracked under spec#4).