feat(drive): expose resolve/reopen action on comments reply (#623)

[sebsnyk]

Summary

Closes #623.

Drive REST API's Reply resource accepts an action field — "resolve" or "reopen" — that atomically flips the parent comment's resolved state when the reply is created. gog drive comments reply previously only accepted content, leaving two bad options for batch-processing inline doc-review feedback:

1. drive comments delete — destroys thread context; only acceptable for self-comments.
2. Click "Resolve" in the Docs UI per thread — doesn't scale past ~10 comments.

This PR exposes both API actions in both shapes the issue offered, with overlap intended:

• gog drive comments reply <fileId> <commentId> <content> --action=resolve|reopen — closer to the API shape, composes with existing reply muscle memory.
• gog drive comments resolve <fileId> <commentId> [--message=...] and gog drive comments reopen ... — sibling verbs mirroring the existing docs comments resolve pattern; more discoverable.

For docs-surface parity, docs comments reply --action=... and a new docs comments reopen verb are also added.

Implementation notes

• createDriveReplyWithAction (in internal/cmd/comment_ops.go) generalises the existing createDriveReply; the existing resolveDriveComment becomes a thin wrapper, so the existing docs comments resolve path is unchanged. reopenDriveComment added.
• validateDriveReplyAction centralises enum validation; also wired to the kong enum tag on the --action flag.
• writeDriveReplyMutationWithAction renders the right envelope key (resolved: true vs reopened: true) per action; the original writeDriveReplyMutation is preserved as a thin wrapper so existing callers and existing JSON output shapes are bytewise unchanged.
• No changes to fields requested by Fields(...) beyond the existing driveResolveReplyCreateFields constant, which already includes action.

Tests

New tests in internal/cmd/drive_comments_resolve_test.go use an httptest.Server to capture the outgoing replies.create request body and assert the action field reaches the wire correctly:

• reply --action=resolve posts action="resolve" and emits resolved: true envelope.
• reply --action=reopen posts action="reopen" and emits reopened: true envelope.
• Plain reply (no --action) emits no action field and the original {"reply": ...} envelope (regression guard).
• Sibling drive comments resolve and drive comments reopen verbs.
• drive comments resolve without --message (action-only reply, no content).
• Invalid --action=ignore is rejected by kong before any network call.
• docs comments reopen parity test.
• Validation-error unit tests for new commands mirroring the existing TestDocsComments_ValidationErrors style.

go test ./... is green locally.

Use case

Batch-resolving inline review feedback on Google Docs from a PM workflow — reply with the substantive resolution AND mark the thread resolved in a single command, scriptable across dozens of threads. This is the PM workflow that motivated #623.

Test plan

• go test ./... green
• gofmt -l clean on touched files
• go vet ./internal/cmd/... clean
• No changes to existing JSON output shapes (regression guarded by TestDriveCommentsReply_NoActionUnchanged)
• Existing docs comments resolve JSON envelope unchanged

🤖 Generated with Claude Code