Integration: rule evaluation ordering & precedence vs hooks (in-transaction)

[rrrodzilla]

Workstream: Integration · Part of #89

Context

All three rungs of the escalation ladder (#89) participate in a single write, and we must define one coherent ordering across them — not just rules-vs-hooks:

1. Rules (CEL) — pure, in-transaction, before persistence.
2. gRPC hooks — before_* (blocking, pre-persistence) and after_* (detached, post-persistence) (crates/schema-forge-acton/src/hooks/mod.rs).
3. Webhooks — outbound, fire-and-forget, dispatched on CRUD events alongside after_change; never block the response, retry with backoff (crates/schema-forge-acton/src/webhook.rs; dispatch in routes/entities.rs).

Defining this lets us also leverage that rules fix the documented hook reentrancy/ordering/consistency caveats.

Scope

• Full write sequence: rule defaults → rule compute → rule validate → before_* hooks → persist → { after_* hooks, webhook dispatch }.
• All rules evaluate in-transaction before persistence; specify precedence between rules and before_* hooks (rules first — they're pure and cheap, and can short-circuit before a network round-trip).
• Pin down the post-persistence fan-out: relative ordering (if any) of after_* hooks vs. webhook dispatch, and that both are detached so neither blocks the API response.
• Guarantee determinism for the in-transaction phase (engine-controlled ordering) and no rule reentrancy.
• Confirm a rule abort prevents persistence and suppresses the post-persistence fan-out (no webhook/after_* fires for a rejected write).

Acceptance

• Documented, tested ordering model covering rules, before_*/after_* hooks, and webhooks.
• Rules evaluate in-transaction ahead of before_* hooks; a rule rejection fires no downstream hook or webhook.

---

Dependencies: Suggested order: after at least one capability lands (#92). Soft.

[rrrodzilla]

Landed in f747625 — feat(rules): run @default/@compute/@require ahead of before_* hooks (#105).

Finding: the actual ordering did NOT match the target — before_validate/before_change gRPC hooks were running before the rule phases in all three handlers. Fixed (surgical reorder, no API/type/actor-message changes).

Canonical in-transaction write sequence now enforced in create/update/patch (routes/entities.rs):
owner/tenant/audit injection → @default (insert-only) → @compute → @require → before_* hooks → PERSIST → { after_* hooks, webhook dispatch }

• Rules run first (pure + cheap) so a @require 422 short-circuits before any hook network round-trip and before persistence.
• Audit/owner injection still precedes the rule phases, so Rules: expression-valued defaults — @default(expr: ...) #94's @owner-beats-@default precedence holds.
• Post-persistence fan-out (after_* via HookDispatchActor, webhook dispatch) stays detached; a rejection suppresses it entirely.

Tests: rule_phase_order_default_then_compute_then_require_is_observable (compute reads a defaulted sibling; require validates the computed value), require_rejection_fires_no_before_or_after_hook_and_persists_nothing, passing_require_reaches_before_and_after_hooks. Authoritative ordering documented on the rules/hooks module docs and docs/rule-ordering-reference.md. clippy -D warnings clean; full acton suite green under --features surrealdb.