Move to go-utils v1.1.8

[juicycleff]

One line of go.mod, and nothing in this repository behaves differently because of it. The reason to take it is what it makes possible next.

What v1.1.8 fixes

bindQueryParam now fills a []string from every occurrence of a repeated query parameter, the way bindFormParam already did. A lone value still expands on commas, so scope=openid,profile keeps working exactly as before, and header parameters are untouched.

The bug it closes was the quiet kind. Before setFieldValue grew a slice case, a []string query field failed the request outright with "unsupported field type". After that, the binder read one value and split it on commas, so the request succeeded carrying less than the caller sent. For an RFC 8707 resource indicator that means an access token scoped to fewer audiences than the client asked for, with nothing logged and nothing to notice.

What changes here

Nothing yet, and that is deliberate. resourceParams still reads the indicator off the raw request, the spec and all three SDKs regenerate byte-identical, and the full suite passes. Verified on this branch rather than assumed:

• go build ./... clean, go mod tidy produces nothing beyond the bump
• regenerating the spec, all three SDKs and both embedded clients leaves only go.mod and go.sum modified
• go test ./... exit 0

What it unblocks

/authorize reads the query string by hand today, and #74 documented the parameter with a WithQuerySchema struct that nothing binds to. That split existed because the query side of the binder would have dropped every resource after the first. With v1.1.8 the hazard is gone, so the parameter can become a real bound field and resourceParams can go with it.

It also matters for #77, which left a skipped spec test naming this exact go-utils change as its precondition. That test should be runnable once this lands and #77 is resolved against the current main.

Worth flagging for whoever picks that up: #74's commit message explains resourceParams as necessary because the binder cannot decode a []string. As of v1.1.8 that reasoning is history rather than a live constraint.

[juicycleff]

Folding this into #76 instead. That branch is the one that actually needs v1.1.8: its commit is marked BLOCKED on xraph/go-utils#4, and three tests in plugins/oauth2provider fail without it. A standalone bump changes nothing on its own, so it belongs next to the code it unblocks rather than in a PR of its own. Same commit is now 7c3f53a on feat/oauth2-authorize-resource-param.