Bug(expr): repr_sh and repr_py do not match the Python functions RFC 0006 names for them

[uberware]

Summary

RFC 0006 defines repr_sh by reference to Python's shlex.quote and repr_py by reference
to Python's repr. Neither output matches for inputs containing a single quote:

Input "it's"	Named Python function produces	Implementation produces
repr_sh	'it'"'"'s' (shlex.quote)	"it's"
repr_py	"it's" (repr switches quote style)	'it\'s' (always single-quote, escapes)

repr_sh's output here is still shell-safe — this is a conformance/portability question
rather than a safety one: two implementations both "following shlex.quote" will embed
different bytes into command lines, which matters the moment output is compared, cached, or
hashed.

Versions

• openjd-model 0.11.1 and 0.11.2 from PyPI
• openjd-rs main at 1a89f3a — still reproduces

Reproduction

import shlex
from openjd.expr import parse_expression
r = parse_expression("repr_sh(\"it's\")").evaluate_with_metrics()
print(str(r.value), "vs", shlex.quote("it's"))
r = parse_expression("repr_py(\"it's\")").evaluate_with_metrics()
print(str(r.value), "vs", repr("it's"))

Suggested resolution

Either match the named functions byte-for-byte, or reword the spec to name the property
(shell-safe quoting; Python-literal round-tripping) rather than the function. Happy to file
against the spec instead if that's the preferred fix.

[mwiebe]

I found that while both Python and Rust have shlex libraries available to make safe-quoted output, they don't produce the same results. I'd favour rewording the spec to specify the safe-quoting property over forcing one exact implementation. What do you think?

[uberware]

Yes, rewording the spec makes sense, given this is Python shlex vs Rust shlex, both shell-safe.

Two asks:

1. make the property testable: "the output, parsed by a POSIX shell, yields exactly one word equal to the input, and N words for a list of N" so the conformance suite has something to assert
2. repr_py is a separate case. There's no library disagreement behind it; repr is a single language-defined function, and the property in play is Python-literal round-tripping rather than safety. Happy to take repr_py either way, but it's different than the shlex argument.

Also worth deciding deliberately: repr_cmd/repr_pwsh are specified byte-exactly with worked examples, so property-wording repr_sh alone leaves the family inconsistent.