[Feature]: msteams: resolve team SharePoint site dynamically for channel file uploads

Summary

When a bot sends files in a Teams channel, allow automatic resolution of the team's own SharePoint site instead of requiring a hardcoded sharePointSiteId.

Problem to solve

Bots that send files in Teams channels must configure channels.msteams.sharePointSiteId pointing to a single SharePoint site. The native Teams file card uses webDavUrl, which requires the recipient to be a member of that SharePoint site. In multi-team deployments, team members who are not members of the configured site see "request access" when clicking a file the bot sent — even though they are members of the Teams team the file was sent in.

This is a real production issue: a bot deployed across four Teams teams uploaded all files to a private SharePoint site. Members of one team could not open files the bot sent because they had no access to that site. The bot operator had to either manually grant every team's M365 group read access to the site, or maintain per-team sharePointSiteId overrides — neither of which scales.

Proposed solution

When sharePointSiteId is absent from config:

1. Resolve the team's M365 group ID from the activity (already cached by resolveTeamGroupId)
2. Call GET /groups/{groupId}/sites/root?$select=id to get the team's backing SharePoint site ID
3. Cache the result (site IDs are stable)
4. Upload files there instead

Files then land on the team's own SharePoint site where all team members already have read access. webDavUrl in the file card works without additional permission grants.

Additionally, make the upload folder name configurable via sharePointFolder (default: OpenClawShared) so deployments can customize it.

sharePointSiteId remains as an explicit override for deployments that want a central upload site.

Alternatives considered

• Use the org-wide sharing link in the file card instead of webDavUrl: OpenClaw already creates an org-scoped sharing link via createLink, but the file card uses webDavUrl. Switching to the sharing link would make files accessible to anyone in the org, removing per-team privacy isolation. This is a weaker solution for enterprise deployments.
• Require operators to grant site access per team: Manual, does not scale, and grants broader access than needed (entire site vs just uploaded files).
• Per-team sharePointSiteId in config: Verbose, requires operators to resolve site IDs manually for every team. Dynamic resolution removes this burden.

Impact

• Affected: Multi-team msteams deployments where the bot sends files
• Severity: High — file sends appear to work but recipients cannot open the files
• Frequency: Every file send in every team except the one whose site matches the config
• Consequence: Users see "request access" on files the bot sent; operators must manually manage SharePoint site permissions per team

Evidence/examples

Production deployment across 4 Teams teams. File sent by bot in Team A's channel → uploaded to /sites/bot-private → Team A member clicks file card → "request access" because they are not a member of /sites/bot-private. The bot operator can open it fine because they are a site admin.

With the proposed change, the same file would upload to /sites/TeamA/ (the team's own backing site) where the team member already has read access.

Do you plan to open a PR for this?

Yes, I plan to implement this myself

Additional information

• Requires Sites.Read.All or Sites.ReadWrite.All on the bot's app registration (most deployments already have Sites.ReadWrite.All for uploads).
• The resolveTeamGroupId cache from team-identity.ts is already populated on every inbound message, so the group ID is available without an extra API call.
• Site ID resolution adds one Graph call per team on first file send; the result is cached for the process lifetime.
• Backward-compatible: sharePointSiteId still works as before when set.

Start with team-identity.ts and the existing resolveTeamGroupId cache, then trace the msteams file-upload path that uses sharePointSiteId and createLink. Implement dynamic Graph site resolution and caching when no override is configured, support sharePointFolder, and preserve the explicit override behavior; done means uploads use the team's site and file cards remain accessible to its members.