fix: list_my_todos/list_my_events honor GITLAB_TOKEN fallback (1.18.1)

[ttpears]

Summary

The actual blocker behind "list_my_todos still fails" wasn't the GraphQL shape (1.18.0 fixed the real schema bugs) — it was a handler-level guard:

const credentials = input.userCredentials ? validateUserConfig(input.userCredentials) : userConfig;
if (!credentials) {
  throw new Error('list_my_todos requires user authentication — ...');
}

That short-circuits the four-step token resolution in `getClient()`. With no per-call user credentials (e.g. stdio mode + `GITLAB_TOKEN` env), the handler throws before `getClient()` can fall back to the env token — even though that token is a real user's PAT and `currentUser` would resolve from it just fine.

Same bug class as 1.15.1 ("write tools honor GITLAB_TOKEN fallback"). That fix patched the write tools but missed these two me-scoped read tools — `list_my_todos` was added later in 1.16.0, `list_my_events` existed before but wasn't part of the 1.15.1 audit.

Fix: drop the guard from both handlers. Let `getClient()` decide. With no env token AND no per-call creds, the user gets a clean error from `getClient()` instead.

Reproduction (stdio, GITLAB_TOKEN set)

• 1.18.0: `list_my_todos requires user authentication — the to-do inbox is scoped to the caller`
• This fix: returns the user's todos (validated against the live schema in the previous PR — schema-level fixes from 1.18.0 still apply)

Test plan

• `npm run build` clean
• Reproduced original failure against 1.18.0 in current session
• CI green
• After merge: re-test list_my_todos and list_my_events from the same client that was failing