fix(request): no dangling ? on empty query strings; feat(auth): doc-level OCI env var indirections

[jeffreyaven]

Two changes, bundled because both gate the oci provider release: the first is required for any
OCI write operation to work at all, the second enables zero-config auth from the provider doc.

1. Never emit a dangling ? for an empty query string (fix)

operation_store.go built every request URL as path + "?" + query even when the encoded query
was empty. url.Parse records the trailing ? as ForceQuery and reproduces it on the wire and
inside the signed (request-target). Servers that normalise the request line before signature
verification then reconstruct post /20160918/vcns against a signature over
post /20160918/vcns? -> verification fails. Live OCI rejects every no-query body verb with
401 NotAuthenticated / Failed to verify the HTTP(S) Signature; GETs escape because OCI list
calls always carry real query params (?compartmentId=...).

Signed-mock suites cannot catch this class of defect: the dangling ? is self-consistent between
signing and wire, so digest and signed-header checks all pass. It was found by bisecting a live
failure (official-SDK signer probe succeeded where the engine failed) and confirmed with a raw
header/URL dump at the mock.

The fix appends ? (or & for paths with embedded queries) only when the encoded query is
non-empty:

encodedQuery := q.Encode()
rawURL := path
if encodedQuery != "" {
    separator := "?"
    if strings.Contains(path, "?") {
        separator = "&"
    }
    rawURL = fmt.Sprintf("%s%s%s", path, separator, encodedQuery)
}
u, err := url.Parse(rawURL)

2. Doc-level OCI env var indirections for oci_signing_v1 (feat)

A provider doc may now ship default env var names in its config.auth block, so a populated
environment needs no runtime --auth context - matching the credentialsenvvar convention of
the API-key auth types:

config:
  auth:
    type: oci_signing_v1
    tenancy_ocid_envvar: OCI_TENANCY
    user_ocid_envvar: OCI_USER
    oci_fingerprint_envvar: OCI_FINGERPRINT
    oci_private_key_path_envvar: OCI_KEY_FILE
    oci_passphrase_envvar: OCI_PASSPHRASE

Key set: tenancy_ocid_envvar, user_ocid_envvar, oci_fingerprint_envvar, oci_private_key_envvar,
oci_private_key_path_envvar, oci_passphrase_envvar, oci_region_envvar. Indirections only - literal
credential values remain runtime-auth-context territory. Plumbed through
internal/anysdk/auth_dto.go, pkg/authsurface.AuthDTO and the public/formulation wrapper
(new getters GetOci*EnvVar()); the API growth check is unaffected (methods on existing
interfaces, no new exported types). The consumer wire-through (mapping the doc-level getters onto
the runtime AuthCtx in transformOpenapiStackqlAuthToLocal) is tracked as a stackql issue.

Verification

• go build ./... and go vet clean (vet findings in registry.go are pre-existing).
• Consumed by a local stackql build (go.mod replace) and verified against a live OCI Always
  Free tenancy (ap-melbourne-1): 18/18 smoke assertions including the full instance state walk
  (launch -> RUNNING -> STOP -> STOPPED -> START -> RUNNING -> rename -> terminate ->
  TERMINATED), VCN/subnet/bucket lifecycles, and both signed forms (three-header GET/DELETE,
  six-header POST/PUT).
• The oci provider's signed-mock integration suite (26 checks) now rejects a dangling ? exactly
  as live OCI does, so a regression fails the suite rather than only surfacing live.

Release

Suggest cutting v0.5.4-alpha02 from this branch for the pending stackql release - the oci
provider publish is gated on a released stackql that carries change 1.