outlook_email_search folderName resolution

### What happened?

outlook_email_search returns NOT_FOUND for mail folders that exist in the mailbox. The failure is deterministic by alphabetical rank: the 10th folder resolves, the 11th does not. Standard Exchange system folders are affected — Conversation History returns NOT_FOUND in a mailbox where it plainly exists.

The tool description states that folders outside a hardcoded well-known list are resolved by enumerating the mailbox's folders. That enumeration appears to read only the first page of Microsoft Graph's mailFolders collection, which defaults to 10 items. Names beyond it are unresolvable.

Inbox, Sent Items and Drafts resolve correctly despite not appearing in the enumerated 10, consistent with them being hardcoded rather than looked up.

Authentication, tenant consent and connection all succeed. This is not an auth or connectivity issue.

### What did you expect to happen?

folderName resolves any folder present in the mailbox, or returns an error that distinguishes "does not exist" from "was not in the enumerated page."

### Steps to reproduce

1. Any mailbox with more than 10 folders at the root. No test data needed.
2. read_resource with uri mail:///folders/ — returns the complete flat folder list with IDs. Note the alphabetical ordering.
3. outlook_email_search with folderName: "Conversation History" — NOT_FOUND. Standard Exchange folder, present in every mailbox, sorts past the 10th position.
4. outlook_email_search with the 11th folder from step 1 — NOT_FOUND.
5. outlook_email_search with the 9th folder from step 1 — succeeds, returns messages and a correct totalResultCount.
6. Synthetic variant: on a clean mailbox create zz-01 … zz-12 at the root. The first one or two resolve; the rest do not, since default system folders consume most of the ten slots.

### Area

Tool Discovery / Invocation

### MCP Server (if applicable)

Microsoft 365 (Anthropic-hosted, microsoft365.mcp.claude.com)

### Error messages or logs

```shell
{
"code": "NOT_FOUND",
"message": "NOT_FOUND: Folder with name \"Conversation History\" not found.
Call read_resource with uri \"mail:///folders/\" to list available folders.
If you meant to filter by a person, use the sender or recipient parameter
instead of folderName.",
"details": { "paramKeys": ["folderName", "limit"] }
}
```

### Additional context

The error text points at mail:///folders/, which returns the complete list correctly in the same session with the same token. The full enumeration exists; it is not wired into the resolver.

Suggested fix: resolve folderName through that same complete enumeration, or use a Graph $filter=displayName eq '…' query rather than client-side matching against a partial page.

Impact: in a mailbox with ~200 folders across several branches, roughly three-quarters become unaddressable by name, and which quarter survives is an accident of alphabetization. The user-visible symptom is Claude stating a folder does not exist while it sits open in Outlook. Silent — no warning, no partial-result indicator.

Same failure class reported against a competing Outlook connector (different cap, same three symptoms): https://community.openai.com/t/outlook-connector-workspace-agents-folder-discovery-capped-at-500-folders-deep-wide-subfolders-are-invisible-search-by-exact-name-path-returns-empty/1382799