[FEATURE] Carry the naked upstream HTTP status code through the provider invoker boundary

Description

providerinvoker.Result is currently {Body any, Messages []string}. The anysdkhttp invoker consumes the *http.Response internally, so consumers (stackql) never see the upstream HTTP status code as a value. The status survives only as text embedded in error message strings, and only when the error body parses into the shapes that processHttpResponse formats as:

HTTP response error.  Status code 403.  Detail: '...'
Response error.  Status code 403.  Body: {...}

Error bodies published verbatim (non-object JSON, HTML, XML, plain text) carry no structured status fragment at all.

Impact

stackql/stackql#670 (MCP tools must distinguish "query ran, zero rows" from "query failed upstream", with 404 mapping onto an empty result set under database semantics) had to be implemented in stackql by regex-parsing status codes back out of message text:

• (?i)status code:?\s*(\d{3}) in two packages (internal/stackql/execution and internal/stackql/mcpbackend), plus
• a deliberately loose (?i)\b404\b|not\s+found fallback for unstructured bodies.

That is fragile by construction, duplicated, and imprecise for the verbatim-body case.

Proposal

Expose the status code on the invoker result, eg:

type Result struct {
	Body       any
	Messages   []string
	StatusCode int // 0 when no HTTP exchange occurred
}

or alternatively a typed upstream error carrying StatusCode. Additive and backwards compatible. The invoker sets it from the final httpResponse.StatusCode on both success and error paths, including the parsed-error-envelope (HasError) path and the verbatim-body path.

Companion

stackql-side consumption is tracked in ; on completion stackql deletes both regexes and the loose fallback.