fix: calendar_id validation rejects valid IDs with @ and . chars

[lishuceo]

Summary

• validateToken() regex ^[A-Za-z0-9_-]+$ was too strict, rejecting valid calendar IDs containing @, ., =, +, : characters
• Added CALENDAR_ID_RE regex specifically for calendar_id that allows these chars while still blocking path traversal (/, \, .., spaces)
• Fixes repeated feishu_calendar tool error ("无效的 calendar_id") when querying shared/subscribed/Google calendars

Evidence from logs

{"err":"无效的 calendar_id: 仅允许字母、数字、下划线、横线","action":"list_events","msg":"feishu_calendar tool error"}

Multiple occurrences across March 23-26.

Test plan

• Added test cases for calendar_id with @, ., =, +, : chars
• Verified path traversal (../, /) still rejected for calendar_id
• Verified strict validation still applies to non-calendar tokens (doc_token, folder_token)
• CI tests pass

🤖 Generated with Claude Code

[claude]

Claude encountered an error —— View job

---

I'll analyze this and get back to you.

[claude]

Claude finished @lishuceo's task in 1m 2s —— View job

---

PR Review: #194 — calendar_id validation

✅ Approved — Clean, well-scoped fix with good test coverage.

What changed:

• New CALENDAR_ID_RE regex (/^[A-Za-z0-9_@.=+:-]+$/) for calendar_id fields, allowing @, ., =, +, : characters that appear in Google/shared calendar IDs
• Strict TOKEN_RE still enforced for all other token types (doc_token, folder_token, etc.)
• Caller in calendar.ts:195 already passes 'calendar_id' as the name, so the branching works correctly

Security check:

• Path traversal chars / and \ are still blocked (not in character class) ✅
• Spaces blocked ✅
• Empty strings blocked (regex requires +) ✅
• event_id on calendar.ts:196 still uses strict validation ✅

Minor note (not blocking): The doc comment on line 6 says "仍禁止 .." but the regex does allow consecutive dots (e.g., abc..def). This is fine since .. is only a traversal risk when paired with / or \ (both blocked), but the comment is slightly imprecise.

Tests: 3 new test cases covering valid calendar IDs, path traversal rejection, and strict validation for non-calendar tokens — good coverage.