Create composite engine

[satyakigh]

Summary

Adds a CompositeEngine and makes it the default --engine. It evaluates every built-in rule with the CEL engine and layers caller-supplied custom rules on top in all three formats - CEL (.json), Rego (.rego), and CloudFormation Guard (.guard). Custom CEL rules run in the CEL engine that owns the built-ins; custom Rego and translated Guard rules run in a separate external-only Rego engine that is constructed only when such rules are supplied. With no custom rules the composite produces diagnostics byte-identical to the standalone Rego and CEL engines, so rego == cel == composite is now a corpus-wide invariant.

The motivation is performance: CEL evaluates the built-in rule set substantially faster than Rego, but until now choosing CEL meant giving up custom Rego rules. The composite gives CEL speed on the built-ins without losing any custom-rule capability.

Performance

Measured with the performance-harness (warm per-validate, median of 5 launches, local macOS arm64):

	composite / rego	composite / cel
Steady-state per-validate (geomean, 19 workloads)	0.45× (~2.2× faster)	1.00× (parity)
Cold init + first validate (geomean)	0.81×	≈1.0×

The gap widens on rule-heavy templates (many_resources 5.2×, unique_500 5.1×) and narrows on templates dominated by shared model/schema work (security-combined-conditions 0.92×).

With a large custom Rego rule set on both engines (security/many_resources.yaml, warm per-validate; both engines emit identical findings):

custom Rego rules	rego	composite	speedup
0	70.2 ms	13.5 ms	5.2×
10	72.2 ms	16.5 ms	4.4×
100	94.0 ms	27.1 ms	3.5×
200	120.0 ms	40.1 ms	3.0×

Composite wins on both the fixed built-in floor (13.5 ms vs 70 ms) and the marginal per-rule cost (0.13 ms/rule vs 0.25 ms/rule), because its external Rego engine loads only the caller's rules rather than the full built-in policy set. The speedup approaches ~1.9× asymptotically as custom Rego rules dominate; it never inverts.