Harden CLI input validation for AI/LLM callers

[jpoehnelt]

Summary

When the CLI is invoked by an LLM agent, unexpected or adversarial inputs can produce confusing errors or unsafe behavior. This issue tracks hardening work beyond the URL encoding fixes in #21.

High Risk — User Input → Side Effects

Area	Risk	Example
gmail/watch.rs output_dir	Path traversal on local filesystem	--output-dir "../../.ssh" writes message JSONs to arbitrary dirs
gmail/watch.rs msg_format	Unexpected API param	Unvalidated string passed to API
events/subscribe.rs output_dir	Same path traversal risk	Same pattern as gmail watch
modelarmor.rs template names	Template path from config → API URL	Config injection
script.rs visit_dirs	Filesystem traversal in Apps Script uploads	Reads files from user-specified paths

Medium Risk — Bad Input → Confusing Errors

Area	Issue
JSON body construction	Malformed --message or --body values produce invalid JSON, yielding opaque API errors
Date/time parsing	Malformed --date or --within values → unclear panics or silent defaults
Flag combinations	Invalid flag combos (e.g. --name + --all) may not all be validated

Recommended Actions

1. Add proptest property-based tests for URL safety helpers and input parsing functions
2. Validate output_dir paths — canonicalize and check they are under CWD or a safe parent
3. Add a --dry-run flag for workflows — LLMs can preview what API calls will be made without executing them (biggest UX win for AI callers)
4. Validate msg_format against an allowlist (full, metadata, minimal, raw)
5. Consider cargo-fuzz targets for persistent fuzzing in CI nightly runs

Context

PR #21 introduced encode_path_segment() and validate_resource_name() helpers in src/helpers/mod.rs to address the most critical URL injection issues. This issue covers the remaining attack surface.