Hooks, interceptors, and policies

• Policies may allow, deny, or add predicates before an operation reaches SQL.
• Query interceptors may inspect or transform query specifications and outcomes.
• Mutation hooks wrap creates, updates, deletes, and relationship changes.
• Transaction-bound clients inherit their context, policies, interceptors, hooks, and field codecs.

Policies can narrow a query or mutation's selection, but cannot widen the caller's filters. Identity, optimistic-version, and relationship-key conditions remain required even when a policy replaces its predicate. A policy that selects the current tenant therefore still respects .id_eq(id) and the version supplied to an optimistic update.

An upsert that conflicts with an inaccessible row returns a policy denial without exposing that row's unique values or database constraint details. The same rule applies when another unique key conflicts.

Relationship filters and traversals prepare policies for every participating entity. For example, user().has_posts() considers only posts visible under the post policy, while user().query_posts() also respects the source user policy. Denying an entity prevents accessing it through a relationship as well as directly. Query inspection applies these same preparation rules before showing the SQL.

After-hook failure and cancellation are rollback conditions. Rent tests these boundaries so a hook cannot report failure after leaving its write committed.