Ambiguity in runtime expressions embedded in strings

[char0n]

The Arazzo Runtime Expression grammar's CHAR rule (specifically the unescape production) currently allows { (%x7B) and } (%x7D) characters within expression names.

This is problematic because runtime expressions are embedded in template strings using {expression} syntax (e.g., "client_id={$inputs.clientId}").

When CHAR permits these characters, an expression like $inputs.foo} becomes valid and consumes the closing brace,
making it impossible to reliably parse where an embedded expression ends. The fix is to exclude { and } from the unescape rule by changing %x5D-10FFFF to %x5D-7A / %x7C / %x7E-10FFFF (where %x7B is {, %x7C is |, and %x7D is }), ensuring the grammar correctly stops at expression boundaries.

$request.body#/... and $response.body#/... expressions with JSON pointers cannot be reliably extracted from {expression} syntax. This is because RFC 6901 (JSON Pointer) allows the } character in pointer paths, making it impossible to determine where the expression ends.