docs: alias tables now accessible via read-only storage (persisted alias views)

[MonikaFeigler]

Summary

• storage/tables/index.md — Added explanation that alias tables are automatically materialized as database VIEWs, making them accessible in workspaces and transformations via read-only storage access without any input mapping configuration. Notes that filtered aliases are supported (WHERE clause enforced in the VIEW) and that alias VIEWs are mirrored to linked bucket projects.
• transformations/mappings/index.md — Removed the limitation stating read-only input mappings cannot access alias tables; replaced with positive statement that aliases (including filtered and linked-bucket aliases) are fully accessible.
• workspace/index.md — Same update as mappings — alias tables including filtered ones are accessible via read-only input mappings in workspaces.
• transformations/snowflake-plain/index.md — Updated the Bucket Objects for Read-Only Input Mapping section accordingly.
• catalog/index.md — Updated two places: (1) the sharing constraint now correctly states filtered aliases are shared as VIEWs with the WHERE clause enforced; (2) removed the "no filter" requirement from the "Adding new tables to an existing shared bucket" instructions.

Context

Previously, alias tables were metadata-only — no physical database object existed, so they were invisible to workspaces, transformations using read-only input mapping, and linked bucket projects. With the Persisted Alias Views feature, every qualifying alias is automatically materialized as a database VIEW, making aliases first-class citizens in storage.

Test plan

• Verify alias table is visible and queryable in a workspace via read-only storage access
• Verify filtered alias (e.g. WHERE status = 'active') is accessible via read-only input mapping in a transformation
• Verify alias from a linked bucket is accessible in the destination project

🤖 Generated with Claude Code