[BUG] SIGSEGV at plan build for EXEC methods whose response schema lacks an exec parameter property (nil schema admitted into tabulation, typed-nil guard defeated) #705

Summary

EXEC against any method whose 2xx response schema is an object without a property matching an exec parameter name (typically id) crashes the binary with a nil pointer dereference at plan build, before any HTTP call or credential resolution.

Depends on / related to: stackql/any-sdk#122 (typed-nil Schema interface returned by the formulation wrappers).

Steps to reproduce

No credentials required:

stackql exec "registry pull okta"
stackql exec "EXEC okta.users.users.activate_user @id='dummy', @subdomain='dummy'"

Result:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0xc8 pc=0x1b06dd5]

goroutine 1 [running]:
github.com/stackql/any-sdk/public/formulation.(*wrappedSchema).GetType(...)
	.../any-sdk@v0.5.3-alpha11/public/formulation/wrappers.go:1378
github.com/stackql/stackql/internal/stackql/drm.(*staticDRMConfig).GenerateSelectDML(...)
	.../internal/stackql/drm/drm_cfg.go:725

Control case that works: EXEC okta.users.users.expire_password @id='dummy', @subdomain='dummy' (its User response schema has an id property). In the okta provider alone, 33 operations across 12 services are affected (activate_user, reactivate_user, factor lifecycle ops, credential ops, key clone/rotate, brand asset uploads, execute_inline_hook, etc.) - any provider with the same response shape is exposed.

Mechanism

1. internal/stackql/primitivegenerator/unary_selection.go (~L88-110): when projecting exec columns, a column absent from the response schema is deliberately admitted if it matches a method parameter - but with foundSchema == nil, which is pushed into the tabulation via formulation.NewColumnDescriptor(..., foundSchema, ...).

2. any-sdk's wrapper factory converts that nil into &wrappedSchema{inner: nil} - a non-nil interface wrapping a nil pointer (stackql/any-sdk#122).

3. internal/stackql/drm/drm_cfg.go:723-725:

if col.GetSchema() != nil {
	typeStr = dc.GetRelationalType(col.GetSchema().GetType())
}

The typed-nil defeats the guard, and GetType() dereferences the nil inner.

Proposed fix

1. Consume the any-sdk fix (stackql/any-sdk#NNN) so nil schemas surface as nil interfaces and the existing guard in drm_cfg.go works.
2. Harden unary_selection.go: when a projected column resolves only as a parameter (no response schema entry), attach a default string schema instead of nil - a param echoed into the projection has a known-serializable type, and this removes the nil from the pipeline entirely rather than relying on downstream guards.

Workaround

Provider-side: strip the response content from affected exec operations (a no-content exec response plans and dispatches correctly). This is what the okta provider build currently does in post-processing, at the cost of not projecting response bodies (e.g. activation tokens).