Add shared materialization policy to content/database adapters

[khaliqgant]

Context

Tracking issue for applying the shared materialization policy from #194 to content/database/wiki adapters where page/database/space expansion can be expensive.

Umbrella: #195

Candidate adapters

• Notion
• Confluence
• Airtable

These adapters should support materialization only where target/resource boundaries are clear and list APIs can avoid fetching full page/table/record content.

Suggested provider shapes

• Notion: targets such as databases/workspaces, resources such as pages/properties/comments/content.
• Confluence: targets such as spaces, resources such as pages/comments/attachments.
• Airtable: targets such as bases/tables, resources such as records/fields/comments if supported.

Exact names should follow existing path-mapper helpers and layout manifests.

Acceptance criteria

• Use adapter-core shared materialization utilities.
• Preserve existing eager/default behavior.
• Avoid pretending generic labels/state filters exist; use provider-native filters such as database, table, space, updated_after, archived, or status where supported.
• Tests cover target matching, selected eager resources, incremental sync, and no-op behavior for unsupported filters.
• README documents supported target/resource/filter names.