fix(lexer): backticks opaque when content is invalid

[mpecan]

Summary

Bash treats the body of `...` as a single word token at the initial lexing stage — errors inside the backtick body are runtime errors, not parse errors. Rable's fork-and-merge parser was rejecting bodies with reserved words in non-reserved positions, unbalanced conditionals, or unterminated ANSI-C quotes — producing <error> output or (worse) silently corrupting the outer AST where bash would produce a plain word.

This adds a scan_backtick_opaque fallback in Lexer::read_backtick_inner: when parse_backtick_body errors, re-scan the body as raw bytes, treating \<x> as a two-byte escape so \` does not terminate. The Ok path is unchanged — valid backticks still produce identical tokens and spans.

Behavior change

Input	Before	After (bash)
echo "`if true then echo a; fi` until "	unterminated double quote	word preserved verbatim
x=`fo<>r i in a b; do echo $i; if done`	unterminated backtick	word preserved verbatim
e else cho ` else echo "hello"`	backtick silently dropped, inner tokens leaked to outer command	4-word command matching bash

Test plan

• cargo fmt
• cargo clippy --all-targets -- -D warnings — clean
• cargo test — 258 passed (was 256; +2 new edge-case tests)
• All 6 backtick_opaque N cases in tests/oracle/bash_valid_divergences.tests removed from KNOWN_ORACLE_FAILURES and now pass
• Unterminated bodies (e.g. `else echo) still surface MatchedPair errors
• Valid backticks (`echo hi`) still go through the fork path — span_backtick test unchanged

Closes #38