[pournasserian]

Closes #2561

What

The first slice of F-RTE (#2421): routing rules and their evaluation (RTE-01, D09). A rule maps conditions on a change set's items and on the set to a disposition. Evaluating the active rules gives a routing decision that names every rule that applied, with its version and reason. This slice decides; the next slice acts on the decision (approvals and auto-publish, RTE-05).

• Core (FluentCMS.Core.Routing):
  • RoutingRuleDefinition, one JSON document with a description, when conditions and then a disposition. It is parsed, validated with every problem reported at once, and written back unchanged.
  • Item conditions are itemKinds, contentTypes, fields (changed field names) and changeKinds. Set conditions are initiators, agents, checks (the worst check outcome allowed) and riskScore. A condition left out matches anything. Checks and score do not match without facts.
  • RoutingDisposition: auto_publish, review with 1 to 10 approvals (1 when left out, RTE-05), or block.
  • RoutingRule mirrors Check: a name, versions and the active version.
  • RoutingEvaluator computes a RoutingDecision: the disposition (or none), the rules that applied with their items and reasons, and the items no rule matched.
• Directory: IRoutingRuleDirectory lists, gets, creates, revises from a named base version, activates and deactivates. Only a person writes; agents and the product's engines get routing_rule_people_only (SEC-02). Each write appends routing_rule.created, .revised, .activated or .deactivated in the same unit of work.
• Routing a set: IChangeSetRouting.RouteAsync(changeSetId) reads the set, its diff for each item's changed fields, each item's content type (taken from the diff's own operations, so both reads agree) (a schema item's own, or an entry's or entity's type) and the initiator, then evaluates the active rules. It is a read: no unit of work and no event.
• Infrastructure: the RoutingRules and RoutingRuleVersions tables, with the definition as jsonb on PostgreSQL. Migrations for both providers. They are generated after v2's newest migration.

Why

D09 has explicit routing rules decide first and a risk score route what they leave. The S1 scenario needs a price rule and a routine spec rule side by side.

Choices worth a look:

• Stored routing rules ahead of the rule book. RUL-02 makes permission and routing a rule kind, but F-RUL (F-RUL: Rule book as versioned content #2419) has not started. As checks did ahead of the rule book (Add check types, checks with test examples and the activation gate #2524), routing rules are their own named, versioned records with an active version that only a person sets. Once the rule book exists, a published permission and routing rule compiles to one of these.
• The strictest disposition wins, and the order of rules never matters. A rule applies when it matches at least one item. Block beats any review, and a review takes the highest approval count. A set auto-publishes only when auto-publish rules cover every item and every field each item changes, and nothing stricter applies. A rule with a fields condition covers only the fields an update changes, and never a change to the item as a whole (a create, a delete, a schema's entity flag or field order), so a spec update that changes name and unit, or that also makes spec an entity type, waits for a score under the S1 rules, while a review or block rule applies as soon as one named field changes. A routine rule therefore cannot carry a risky change through, whichever rule a person wrote first.
• Items no rule matches are listed, not defaulted. The scorer slice (RTE-02) routes them by score, and to a person when no model is configured. Until then the next slice treats an undecided set as needing review.
• Activation validates again and needs no examples, unlike checks: a routing rule only reads facts the product computes.
• Not in this PR: acting on the decision (RTE-05), the risk scorer (RTE-02, RTE-03), sampling (RTE-04), the routing decision log (RTE-06), check results as facts (the checks condition is there, and the check run now exists since Run the checks on every submitted change set #2575, but RouteAsync does not pass its outcome yet, so a checks condition never matches; RTE-05 supplies it), sections, agent trust levels, and screens or tools for routing rules.

Tests

Unit (Core):

• A definition with every condition reads back, round-trips through its JSON, and validates. Conditions may be left out, and a review defaults to one approval.
• Malformed parts are all reported at once, by path. A count or a bound given as text or null is reported with the others. Every problem in a disposition is reported too, and a disposition given as a number is named as an unknown disposition. Approvals are only for a review, from 1 to 10.
• Validation reports bad slugs, field names, duplicates, empty lists, unknown kinds, empty agent ids and inverted or out-of-range score bounds.
• S1: a price change gets review with 1 approval, and a set of only spec name changes auto-publishes. A set with both gets review whichever rule comes first.
• Block beats review, and review takes the highest count.
• An unmatched item is listed and stops auto-publish, and a stricter rule still decides while other items wait for a score.
• An auto-publish rule covers only the fields it names: an item that also changes another field waits, unless another auto-publish rule names that field or covers the whole item. A change to the item as a whole waits unless a rule without a field condition covers it. A create or a delete counts as one, whatever fields it lists.
• Item conditions match by kind, type, changed field and change kind. Set conditions match by initiator kind and agent, and need facts for checks and scores.

Integration, each on SQLite and PostgreSQL:

• A person creates, activates, revises, reactivates and deactivates a rule. The active version stays until a new one is activated, and every write is audited with the version it replaced.
• An invalid definition, a taken name, an unknown rule (on read, revise, activate and deactivate), a stale base, a missing version, re-activating and deactivating an inactive rule fail with their codes and write nothing.
• An agent and the checks engine are refused for every write.
• A schema update that makes a type an entity type is not covered by an auto-publish rule naming the field it also adds.
• A stored set with a schema create, a schema update and an entry create routes by the active rules: the inactive rule is ignored, every item is matched, and no event is appended. The same routine set opened by an agent is undecided, because the rule names people. An unknown set fails with change_set_not_found.

dotnet build -warnaserror and the full suite pass locally on SQLite and against a postgres:17 container. One run had a timing failure in JobQueueWorkerTests (lease) under full-suite load, which passes on its own; this PR does not touch jobs. No new package and no new project reference.

Checklist

• Linked to an issue a maintainer has confirmed
• Targets v2
• Tests or docs updated where behaviour changed
• No tool-generated co-author trailers or footers