fix(orm): authorize public projections with complete SQL visibility

[Dastari]

Behavior

A globally installed RowPolicy currently rejects every typed projection, even for a model explicitly marked unrestricted. Public certificate inventory therefore cannot use its generated DTO without fetching private custody fields.

Use the existing current ReadVisibility contract for pool and pinned-transaction projection reads. Unrestricted permits matching rows; Complete validates the entity/backend and applies the parameterized predicate before ordering, limits and generated key lookups. Callback-only/prefilter policies still fail before SELECTs. Entity and selected-field authorization remain required. No full entity fallback, public GraphQL roots, schema changes or cursor changes.

Generated projections supply a doc-hidden identity through a provided trait method. Existing handwritten implementations compile unchanged and retain unrestricted reads; complete predicates fail closed without a matching identity. ORM/macros are aligned at 0.35.1. This PR follows #99 for the combined static release checkpoint; neither this behavior nor the private example requires runtime A–D. Existing MSSQL generated-projection limitations remain unchanged.

Executed verification

• Reproduced the actual public projection failure at ae67b01d9222fae5787e02b553e9a24c21e31797 with an installed provider returning Unrestricted; the new fixture failed with the legacy projection-denied error.
• SQLite: 27 library, six complete-group, three existing projection and four new projection-visibility tests passed. PostgreSQL: 28 library and four new tests passed on independently owned disposable containers; no ambient application URL or silently skipped execution. Views raise errors if the private-key expression is selected.
• New regressions cover unrestricted/complete visibility, authorization before limit, all pool/transaction fetch methods and generated ID helpers, current policy changes, mismatched entity predicates, residual policies, entity/selected-field denial before query I/O, source compatibility for a handwritten projection, and PostgreSQL RLS/auth intersection with no pooled setting leakage. Actual query observation confirms one bounded SELECT per projection operation and no excluded private column.
• SQLite group pages execute under a global provider for unrestricted/complete visibility and reject residual/mismatched authorization. Existing group tests retain count and cursor behavior.
• SQL-free dependency-minimal policy_projections example executed successfully; external consumer warnings-denied Clippy passed SQLite/PostgreSQL/MSSQL. No direct async-graphql dependency or public CRUD roots.
• Explicit SQLite/PostgreSQL/MSSQL core/macros Clippy and Rustdoc with warnings denied, formatting, documentation (191 governed files), inventory, dependency/release-state checks passed. Explicit package-selected patch semver versus 0.35.0: 223 checks passed, 30 inapplicable checks skipped.

No live MSSQL projection execution is claimed; generated MSSQL projections are unsupported. The older PostgreSQL projection fixture still uses ambient URL selection and is not part of the new execution evidence. The new fixture owns its infrastructure and fails if unavailable.

Documentation impact

• Documentation updated: public API/reference, migration notes, changelog, aligned manifests/fixture locks and generated inventory updated. Canonical projection reference links executable examples and owned PostgreSQL commands.

The source-only release workflow now executes the new owned PostgreSQL projection/relationship lanes and both private examples before publication; its human approval guard is unchanged.

Remaining joined/computed reads, MSSQL summaries/pages and private generated GraphQL views stay open in #91. Release publication uses the coordinated subsequent .3 identity; .2 remains at its AI-only commit.