`gws schema` drops `repeated: true` for array query parameters, causing metadata format to fail

[knaka]

Summary

gws schema omits the repeated: true field for query parameters that accept multiple values. As a result, parameters like metadataHeaders appear as string instead of string[], and passing an array via --params does not expand into repeated URL query parameters as expected.

Environment

• gws version: 0.8.0

Steps to Reproduce

gws schema gmail.users.messages.get

gws schema output for metadataHeaders:

{
  "description": "When given and format is `METADATA`, only include headers specified.",
  "location": "query",
  "required": false,
  "type": "string"
}

Google Discovery API raw response (https://www.googleapis.com/discovery/v1/apis/gmail/v1/rest):

{
  "location": "query",
  "repeated": true,
  "type": "string",
  "description": "When given and format is `METADATA`, only include headers specified."
}

The repeated: true field is present in the Discovery API but missing from gws schema output.

Expected Behavior

1. gws schema should expose repeated: true so users know the parameter accepts multiple values.

2. When repeated: true, passing a JSON array via --params should expand into repeated URL query parameters:

   ?metadataHeaders=Subject&metadataHeaders=Date&metadataHeaders=From
   

Actual Behavior

Passing an array has no effect:

# Does NOT return Subject/Date/From headers — payload.headers is absent
gws gmail users messages get --params '{"userId":"me","id":"<id>","format":"metadata","metadataHeaders":["Subject","Date","From"]}'

Passing a single string works, but only one header is returned:

# Works, but limited to one header
gws gmail users messages get --params '{"userId":"me","id":"<id>","format":"metadata","metadataHeaders":"Subject"}'

The workaround is to use format: "full", which returns the entire message payload — significantly heavier than metadata.

Impact

The metadata format exists specifically to fetch lightweight message metadata. This bug makes it impossible to retrieve multiple headers efficiently, forcing users to fall back to format: "full".