Mock provider: unrecognized bytes become identifiers; non-ASCII input panics #62

Audit finding H1 + M7 — verified live against the release binary.

Problem

conformance/mock-provider/src/puzzle/lex.rs emits an unknown-byte token per byte and the parser accepts those tokens in identifier positions. Two consequences:

• puzzle \u03b1 {\u2026} — a multi-byte char produces a token whose span ends mid-character; position_of in puzzle/text.rs slices text[..byte] at a non-UTF-8 boundary -> panic, exit 101, in-flight request unanswered.
• puzzle @ { ... $: x => x + 1 ... } — illegal bytes are silently accepted as names; lpp/check returns diagnostics: [] and invented names flow into lpp/symbols / reconstruct output.

Reproduction

printf '%s\n' \
 '{"jsonrpc":"2.0","id":1,"method":"lpp/initialize","params":{"protocolVersion":"1.0"}}' \
 '{"jsonrpc":"2.0","id":2,"method":"lpp/check","params":{"documents":{"u":{"uri":"file:///a.xdl","languageId":"x-demo-lang","version":1,"text":"puzzle \u03b1 {\n  target = 1\n  start = 0\n  ops {}\n  solution = []\n}"}}}}' \
 | ./target/release/lpp-mock-provider   # panics: byte index N is not a char boundary

Acceptance criteria

• Bytes outside the x-demo-lang token grammar produce a syntax-error diagnostic, not a valid identifier.
• The provider never panics on non-ASCII document text; every request gets a response.
• Regression tests cover both cases; cargo test --workspace and the conformance suite stay green.