Decide materialization policy design for storage/tree adapters

[khaliqgant]

Context

Storage/tree adapters are likely candidates for lazy materialization, but their economics are different from issue/chat/content records. Before adding config, decide whether the shared materialization policy from #194 maps cleanly to storage trees or whether they need a smaller provider-specific sync scope model.

Umbrella: #195

Candidate adapters

• Google Drive
• OneDrive
• SharePoint
• Box
• Dropbox
• S3
• GCS
• Azure Blob

Design questions

• What is the target key: account, drive, site, bucket, container, folder prefix, or some combination?
• What are the resources: metadata, file content, folders, permissions, comments, versions?
• Should lazy mean metadata-only, index-only, no content bodies, or no child traversal?
• Can provider APIs apply prefix/path, modified_since, MIME type, size, or folder filters cheaply?
• How should webhook/delta events behave for lazy targets?

Acceptance criteria

• Produce a short design note or adapter README update explaining the chosen model.
• If implemented, use adapter-core shared materialization utilities for target/resource rule resolution.
• Preserve current eager/default behavior.
• Add tests for folder/prefix target matching, metadata-only/content lazy behavior, modified_since cursor behavior, and webhook/delta handling.
• If not implemented for a provider, document why materialization policy is not a good fit.