[BUG] request.nativeCasing reverse-resolution unreachable from snake WHERE/INSERT keys

[jeffreyaven]

request.nativeCasing: pascal is meant to let a snake_case SQL key resolve to its
PascalCase wire parameter via the public OperationStore.GetParameter (which already
does reverse-casing). But a downstream consumer that resolves WHERE/INSERT keys against
the wire-keyed parameter set BEFORE calling GetParameter never reaches the reverse-casing
path, so the snake key is rejected.

Repro (stackql stackql_native_test mock, against alpha08)

Method declares query params VpcId/SubnetId with request.nativeCasing: pascal.

-- wire name works, and proves the param is transmitted as Pascal:
select echoed_query from stackql_native_test.casing.echo where VpcId = 'abc123';
-> echoed_query = "VpcId=abc123"

-- snake name (the point of nativeCasing) fails before GetParameter is consulted:
select echoed_query from stackql_native_test.casing.echo where vpc_id = 'abc123';
-> error: could not locate symbol vpc_id

Expected / suggestion

So consumers get this for free through their existing wire-keyed param resolution,
expose the parameter set INCLUDING the snake aliases (or a public resolver that maps a
snake key -> wire Addressable) such that a consumer iterating/looking-up params by name
sees the snake key without having to special-case GetParameter at every resolution site.
Also: a method-level request: block on a GET currently needs mediaType: application/json
or request assembly errors media type '' not supported (MarshalBody on an empty body) -
worth handling a body-less request block.

Impact

nativeCasing has no working path from the SQL surface today; blocks the snake-input
casing assertions and the entra_id provider's ergonomics.