CLI parses string flags containing colons as YAML objects

[john-rtr]

String flag values containing colons (:) are silently parsed as YAML key-value mappings instead of being treated as plain strings. This causes 400 errors from the API because fields like subject and text are sent as objects instead of strings.

agentmail inboxes:messages send \
  --inbox-id "my-inbox@agentmail.to" \
  --to "recipient@example.com" \
  --subject "S4: test" \
  --text "hello" 

With --debug, you can see the request body:

{"subject":{"S4":"test"},"text":"hello","to":"recipient@example.com"}

"S4: test" was parsed as YAML mapping {S4: test} → sent as {"S4":"test"}.

agentmail inboxes:messages send \
  --inbox-id "my-inbox@agentmail.to" \
  --to "recipient@example.com" \
  --subject "BCC test" \
  --text "hello"

In internal/requestflag/requestflag.go, the parseCLIArg function falls through to yaml.Unmarshal for any flag typed as any (rather than explicitly string). Since "S4: test" is valid YAML for a mapping, it gets deserialized as map[string]any{"S4": "test"} instead of remaining a plain string.
The allowAsLiteralString fallback only triggers when YAML parsing fails, so valid-but-unintended YAML like colon-separated strings silently become objects.
This is likely a Stainless CLI framework issue (stainless-api/stainless-api-cli) rather than agentmail-specific, since the requestflag code is generated.

• CLI version: 0.7.4
• OS: macOS (arm64)
• Go: 1.25.8
  Use the REST API directly via curl instead of the CLI for any values containing colons.