feat: chat DM creation, calendar timezone, message filtering, find-group

[omriariav]

Summary

Fixes four issues discovered during real usage:

• calendar create: YYYY-MM-DD HH:MM format fails with 'Invalid time zone definition' #143 — Calendar create/update sent "Local" as timezone, which Google Calendar API rejects. Added resolveIANA() helper that resolves the real IANA zone name from TZ env or /etc/localtime symlink, falling back to omitting the field (RFC3339 offset suffices).
• gws chat: fix DM creation and update skill docs #142 — setup-space required --display-name unconditionally, but the API rejects it for DIRECT_MESSAGE and GROUP_CHAT types. Now validates flags by type: DM/GROUP_CHAT require --members, SPACE requires --display-name.
• Add time filter flag to chat messages command #145 — Added --after and --before convenience flags to chat messages that translate to createTime filter expressions. Combines with existing --filter using AND.
• feat: Add find-group-chat command + local member-to-space mapping cache #144 — Added build-cache and find-group commands with a new internal/spacecache package. build-cache iterates spaces, fetches members, resolves emails via People API, and stores a persistent JSON cache. find-group searches the cache for spaces containing all specified members.
• Updated chat skill docs to v2.2.0 with new commands, fixed setup-space docs, added DM workflow recipe.

Test plan

• go build ./... compiles
• go vet ./... clean
• go test ./... all pass (including new tests for resolveIANA, parseTime, setup-space DM/GROUP_CHAT, after/before filter, spacecache Load/Save/FindByMembers, command registration)
• Codex review passes

Closes #142, #143, #144, #145

🤖 Generated with Claude Code

[github-actions]

Summary
This PR adds timezone resolution for Calendar event creation/update, introduces Chat space-member caching with new chat build-cache and chat find-group commands, and adds --after/--before message filters plus setup-space validation tweaks.

What looks good

• New Chat subcommands are registered and included in cmd/commands_test.go, matching the existing command structure patterns.
• Docs for the chat skill and command reference were updated to cover new flags and commands.
• Unit tests were added for parseTime, resolveIANA, and spacecache behaviors.

Issues found

Warning

1. resolveIANA returns "" to “omit” timezone, but TimeZone is still assigned in Calendar requests. Unless calendar.EventDateTime.TimeZone is tagged omitempty, an empty string will be serialized and may be rejected by the API. Consider only setting TimeZone when non-empty.

   • cmd/calendar.go

2. New commands (chat build-cache, chat find-group) lack httptest-based CLI behavior tests. The repository guidelines explicitly call for mock server tests for new commands. Only flag tests were added.

   • cmd/chat_test.go
   • cmd/commands_test.go

3. README command table wasn’t updated for the new Chat commands and flags, while the instructions require it for new commands.

   • README.md (missing change)

Suggestion

1. Validate --type for chat build-cache and chat setup-space to fail fast on invalid values instead of passing them through to the API. This prevents silent errors and aligns with tighter input validation.
   • cmd/chat.go

If you want, I can suggest specific test cases for the new Chat commands or draft a minimal README update.

Next steps (optional)

1. Add httptest coverage for build-cache and find-group.
2. Gate TimeZone assignment on non-empty resolve.
3. Update README.md command table for the new flags and commands.

[github-actions]

I can’t compute the PR diff: origin/main...HEAD has no merge base in this repo, so Git can’t compare. How do you want to proceed?

Options:

1. Provide the base branch name/commit SHA to diff against.
2. Paste the diff here.
3. Tell me to review git diff HEAD~N..HEAD for a specific N.

[github-actions]

Summary
This PR adds Google Chat member cache tooling (build-cache, find-group), adds --after/--before convenience filters for chat messages, and improves Calendar timezone handling for create/update, plus docs and tests updates.

What Looks Good

• New chat subcommands are registered consistently and documented (cmd/chat.go, README.md, skills/chat/*).
• chat setup-space now validates types and avoids displayName for DM/GROUP_CHAT, matching API behavior (cmd/chat.go).
• resolveIANA and the related tests improve Calendar timezone correctness without breaking RFC3339 offsets (cmd/calendar.go, cmd/calendar_test.go).
• commands_test.go includes the new chat subcommands, following the existing command-structure pattern (cmd/commands_test.go).

Issues Found

1. Warning: Cache build silently populates spaces with zero members on membership list failures.
   In internal/spacecache/cache.go, member list errors break the paging loop but still write an entry with empty members, which can cause false negatives in find-group. Consider skipping the space entirely or returning an error for that space.
   File: internal/spacecache/cache.go

2. Warning: find-group accepts empty/blank emails and can yield no matches unexpectedly.
   In cmd/chat.go, --members is split and trimmed but not filtered; a trailing comma or extra whitespace produces an empty needle, causing FindByMembers to fail matches. Recommend filtering out empty strings and erroring if the resulting list is empty.
   File: cmd/chat.go

3. Warning: Missing command-level tests for build-cache and find-group flows.
   Current tests add flag checks and mock server list/members, but there are no tests that execute runChatBuildCache / runChatFindGroup end-to-end with a temp cache file and mocked Chat/People APIs. Given the project guideline (“new commands need httptest mocking and command structure tests”), coverage looks incomplete.
   Files: cmd/chat_test.go, internal/spacecache/cache_test.go

Open Questions / Assumptions

• Should find-group return empty results (not an error) when the cache exists but contains zero spaces, or is the current “no cache found” error desired?
• Should --after/--before validate RFC3339 locally for clearer error messages, or is letting the API reject invalid values acceptable?

Test Gaps / Notes

• I did not run tests in this environment.

If you want, I can propose concrete test cases and a small patch for the two warnings above.