feat: policy dictionary

[stefan-gorules]

Dictionaries for policies

This PR adds dictionaries to policies: named sets of allowed string values with human-readable labels. A dictionary is declared once as a block and drives typing, input validation and the natural-language projection, while rules keep using plain string literals. A dictionary is not a value: it cannot be referenced from expressions, and it never appears in inputs or results.

What it delivers

A dictionary block declares canonical values and their labels. DataModel property then references it the same way it references an entity, and the field becomes a string constrained to the dictionary:

Where	Effect
customer.tier targeting customerTier	field typed as the enum of dictionary values
customer.tier == 'VIP' in a rule	plain string comparison, type-checked against the dictionary
input { "tier": "GOLD" }	rejected before any rule runs, not a member
decision-table cell on a dictionary-typed field	editor offers labeled options instead of free text

• Values stay strings. Rules compare against ordinary literals; documents store canonical values. There is no dictionary object at runtime and no customerTier.X member syntax. An expression referencing the dictionary by name is an unknown-property diagnostic like any other.
• Membership is enforced at the boundary. Inputs for dictionary-typed fields are validated before evaluation: scalars, array elements and globals alike. Out-of-dictionary values fail input validation instead of flowing through rules.
• Declarations are checked. Duplicate values within a dictionary and name collisions (with another dictionary or with an entity) are edit-time diagnostics.
• Labels drive the editor. A dictionaries() API exposes values with their labels, and the natural-language projection uses them: a 'VIP' literal compared against a dictionary-typed field projects with a select hint whose options are labeled ("Very important", "Standard") and carry ready-to-insert literals; list membership (in, contains, all(...)) gets multi-select hints; an empty decision-table cell offers the labeled values as subject options. Exposed in the Node.js binding as workspace.dictionaries(...).

How it helps

• Business vocabularies such as tiers, regions and statuses are declared once and reused everywhere, instead of string literals scattered through rules that drift out of sync.
• Documents store stable canonical values while labels change freely: renaming "Very important" to "Premium" touches one entry, no rule rewrites, no data migration.
• Editors can render dropdowns and sentence-style rules with human labels, while the engine guarantees only valid values reach evaluation.
• Purely additive: policies without dictionary blocks behave exactly as before.