Let callers choose a runtime when creating a sprite

[dangra]

The create API accepts an optional runtime naming which runtime variant a sprite should be created on. The SDK had no way to send it, so callers were stuck with the default.

Shape

Rather than grow the signature of CreateSpriteWithOrg a third time, this adds CreateSpriteWithOptions taking a CreateSpriteOptions struct, so the next optional setting is a field rather than another positional argument:

sprite, err := client.CreateSpriteWithOptions(ctx, "my-sprite", sprites.CreateSpriteOptions{
    Runtime: "some-runtime",
})

CreateSprite and CreateSpriteWithOrg are untouched at the call site and delegate to it, so this is additive — no existing caller has to change.

The runtime is opaque on purpose

Which names are valid is the API's business, not the SDK's. Keeping it an unvalidated string means a new runtime works without an SDK release, and an unknown one comes back as a server error naming the set that is accepted — better than a client-side list that drifts out of date and rejects something the server would have taken.

An empty runtime is omitted from the request body entirely (omitempty), since sending "" would ask for a variant named "" rather than for the default. There is a test pinning that, because it is the kind of thing a later refactor silently breaks.

Tests

Three, driving a stub server and asserting on the JSON that actually goes out: the runtime is sent when set, omitted when empty, and CreateSpriteWithOrg still carries its config and labels through the new path. go test, go vet and gofmt are clean.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[dangra]

Closing: this is the wrong approach and not something we want to expose in the SDK.