feat(core): `condition.transform` — `json_decode`, `path`, `length`

Three steps, not eight — measured demand concentrates there: JSON-in-string (IAM policy documents
behind jsonencode), path into the decoded value, and length/count. Date arithmetic is the next
largest measured need (e.g. certificate-expiry checks) — a value_type-style coercion layer (age, size, cidr, cidr_size, version,
resource_count) — a shape field-proven at scale in mature policy tooling — is the design
source. Mandatory hardening: wrap each step in
try/except Exception (an OverflowError from date parsing or a RecursionError from
json.loads currently escapes and kills the run), emit meta once per source input (measured
6.7 KB → 159 KB on one 50-container task definition), and treat a null attribute behind a transform
as ProviderError(severity 2). Also the honest answer to the #207 CIDR-evaluator ask. Depends on
the R1 skip-ordering and variable-recursion fixes.

The issue does not name implementation files, tests, or entry points. First resolve the stated R1 skip-ordering and variable-recursion dependencies, then define the three transform steps and hardening requirements; done means those steps, error handling, metadata behavior, and null-attribute handling are implemented without escaping failures.