add worker_subnet_uuid to kubernetes docs

[d-honeybadger]

New field was just added to DOKS API.

[Bala-Nallamilli]

A few questions/suggestions before approving:

• Is worker_subnet_uuid immutable after cluster creation? I noticed cluster_update.yml isn't touched, which suggests this can't be changed post-create. If that's intentional, could we call it out in the description on the create side? Similar to how the ha field documents its behavioral constraints. Something like: "This value cannot be changed after the cluster is created."

• Should there be a scope requirement note? The sibling vpc_uuid field ends its description with Requires \vpc:read scope.Since subnets are a VPC sub-resource, does setting/readingworker_subnet_uuidalso requirevpc:read(or some other scope)? Worth aligning with thevpc_uuid precedent if so.

• Create-request example doesn't demonstrate the new field. The response examples in responses/examples.yml include worker_subnet_uuid, but the curl create example in examples/curl/kubernetes_create_cluster.yml doesn't show a caller actually setting it. Could we add it there so users see how to use the new field end-to-end?

• Minor: The description says "Requires vpc_uuid to be set" — is this constraint enforced server-side with a validation error? Just confirming, since the schema itself doesn't express the dependency (no dependentRequired/oneOf).

Otherwise LGTM — examples coverage is complete and the write/read description split follows the existing pattern nicely.

[d-honeybadger]

Is worker_subnet_uuid immutable after cluster creation?

Yes, added a callout

Should there be a scope requirement note?

Yes, TY! Required vpc:read, same as vpc_uuid

Create-request example doesn't demonstrate the new field.

Didn't realize that was separate from the response examples tbh. Added the field there.

The description says "Requires vpc_uuid to be set" — is this constraint enforced server-side with a validation error? Just confirming, since the schema itself doesn't express the dependency (no dependentRequired/oneOf).

Yes, there is a validation in the API for this. I tried adding dependentRequired, but apparently it's only available in openapi 3.1 and we're on 3.0. And using "oneOf" to express this seems confusing, no? Not even sure how to express this with oneof tbh. If it's okay to just have a description callout, I'd keep it this way.