Microsoft 365 connector's SharePoint tools omit createdDateTime, only return lastModifiedDateTime

### Problem Statement

The Microsoft 365 connector's sharepoint_search, sharepoint_folder_search, and read_resource tools all return lastModifiedDateTime for SharePoint/OneDrive files, but never createdDateTime. Microsoft Graph's underlying driveItem resource exposes both fields natively (createdDateTime and lastModifiedDateTime are both standard properties on every drive item), so this looks like a gap in what the connector's tool schema surfaces rather than a Graph API limitation.

This matters for any workflow that needs to measure how long a document took to produce, versus when it was last touched. In our case, files that are created once and later re-saved for administrative reasons (e.g., swept into a folder consolidation at case close) show a lastModifiedDateTime far later than when the file actually mattered, with no way to recover the true creation timestamp.

Requesting: add createdDateTime alongside lastModifiedDateTime in the response payload for sharepoint_search, sharepoint_folder_search, and ideally read_resource folder listings.

### Proposed Solution

Map Microsoft Graph's existing createdDateTime property on the driveItem resource into the response payload, the same way lastModifiedDateTime is already mapped today. Concretely:

sharepoint_search: add a createdDateTime field alongside lastModifiedDateTime in each returned document object.
sharepoint_folder_search: same addition for each returned folder object.
read_resource (folder listing): include createdDateTime and lastModifiedDateTime per child item, not just name/type/size/URI as it does now.

No new Graph API call or permission scope should be required, since createdDateTime is already part of the standard driveItem object returned by the same Graph endpoints these tools already query (GET /drives/{drive-id}/items/{item-id} and the children-listing equivalent) — this looks like a field that's simply being dropped when the connector formats its tool output, not a data source limitation.

If a backward-compatibility concern is a blocker to changing the default response shape, an acceptable alternative would be an optional parameter (e.g., includeCreatedDate: true) on the affected tools rather than adding the field unconditionally.

### Alternatives Considered

_No response_

### Area

MCP Connector (adding/managing servers)

### Priority

Critical - Blocking my MCP server development

### Additional Context

_No response_