Investigate recurring "Failed to retrieve events from this account" warning for one account

[rockfordlhotka]

Background

Follow-up from #59 (PR #60). During testing, get_calendar_events consistently emits a per-account warning for one account (rockbotagent):

{ "accountId": "rockbotagent", "error": "Failed to retrieve events from this account." }

This is pre-existing and unrelated to #59 — it's the tool's per-account try/catch swallowing a provider exception during the fan-out. The all-accounts fix simply makes it more visible because that account is now always included when accountId is omitted.

Where it comes from

src/CalendarMcp.Core/Tools/GetCalendarEventsTool.cs:116 — the catch block logs the full exception server-side but returns only the sanitized warning to the client:

catch (Exception ex)
{
    logger.LogError(ex, "Error getting calendar events from account {AccountId}", account!.Id);
    lock (warnings)
    {
        warnings.Add(new { accountId = account.Id, error = "Failed to retrieve events from this account." });
    }
    return Enumerable.Empty<CalendarEvent>();
}

Investigation steps

1. Pull the real exception from the deployed server: kubectl -n calendar-mcp logs deploy/calendar-mcp | grep -i "Error getting calendar events from account rockbotagent".
2. Determine the root cause. Likely candidates:
   • The account's credentials/token are expired or never completed interactive auth.
   • rockbotagent is an email-only mailbox (e.g. IMAP/SMTP) that has no calendar capability, so GetCalendarEventsAsync throws rather than returning empty.
3. Decide on the fix based on cause:
   • No calendar capability → skip non-calendar-capable accounts in calendar reads instead of attempting and warning (relates to the capabilities array surfaced by list_accounts). This would also tidy the all-accounts fan-out for mixed account types.
   • Auth/credential issue → re-auth flow / clearer credential-expiry warning.

Acceptance

• Root cause identified from logs.
• Either the warning no longer appears for a correctly-configured account, or it's replaced with an actionable message (e.g. "account has no calendar capability" / "credentials expired — re-authenticate").

Identified during #59 testing.

[rockfordlhotka]

Fixed in #64 (squash-merged to main). Verified against the live cluster on image 1.3.6: the all-accounts fan-out now logs Skipping account rockbotagent in calendar read: no calendar capability and emits no warning, and explicitly targeting the email-only account returns an actionable "no calendar capability" message.