feature: bring the cdk-preflight rule pack (~3,000 deploy-verified constraints) into the engine #473

Feature summary
I maintain cdk-preflight, a Rego rule pack for CloudFormation
constraints that resource schemas do not express. It runs on this engine through the built-in validator in
aws-cdk-lib. Now that #468 has been merged, I would like to move as much of the pack as possible into this
repository, so that every interface gets these checks, not only CDK users. Before I open more PRs, I would like to
agree with you on how to do it at this scale.

Problem or use case
The constraints in the pack live only in service documentation, in service API validation, or across several
properties. Templates that violate them pass this engine and CloudFormation pre-deployment validation, and then fail
during deployment and roll the stack back. E9014 (#467) is one example: five pack rules about EventPattern became one
engine rule.

What the pack contains (as of 2026-10-21; full list: docs/rules.md)

• 3,034 rules that this engine does not cover yet, over 76 services and 383 resource types.
• Every one of them was reproduced against a real account. Each rule has a failing and a passing template, and its
  metadata records the date, the Region and the exact error, for example (shortened):
  bench 2026-09-24 us-east-1: Replicas [{Location: us-east-1}] in a stack deploying to us-east-1 -> "Invalid request provided: Replica location us-east-1 cannot be the same as primary location us-east-1." (ROLLBACK_COMPLETE); pass no Replicas -> CREATE_COMPLETE
• The rules read only the template (Resources, Outputs, Parameters). None of them depends on CDK metadata or on
  account state.

Questions

1. Pace. Is a stream of PRs like feat(rules): validate EventBridge event pattern matchers (E9014) #468 welcome, and how much can you review? For example, one PR per service or per
   resource type, and how many per week.
2. Grouping and IDs. feat(rules): validate EventBridge event pattern matchers (E9014) #468 grouped the checks for one property under one ID, as E3027 does. If I group the rest the
   same way, the number of new IDs is somewhere between one per resource type (about 380) and one per property (more).
   Engine-assigned rules use the 9xxx range. Is that range meant to hold hundreds of new IDs, and which grouping do you
   prefer?
3. Implementation shape. fix: validate SQS timeouts across scenarios E3505 #452 and feat(rules): validate EventBridge event pattern matchers (E9014) #468 put the logic in template-model and call it from both engines (directly
   from CEL, through a builtin from Rego). Should simple single-property checks follow the same shape, or be written as
   a native CEL rule plus a hand-written Rego policy?
4. Built-in or optional. Would you rather have some of these as built-in rules and the rest as an optional rule
   set that ships with the engine (for example as custom Rego, as described in CUSTOM_RULES.md)?
5. Evidence. Is the evidence format of feature: validate EventBridge EventPattern matchers on AWS::Events::Rule and AWS::Events::Archive #467 enough for each group, or would you like it in another form?
6. Where to start. My suggestion is AWS::Pipes::Pipe and Lambda event source mapping FilterCriteria, which use
   the same grammar as EventPattern and can reuse the E9014 code (left as a follow-up in feature: validate EventBridge EventPattern matchers on AWS::Events::Rule and AWS::Events::Archive #467). If another service
   matters more to you, I can start there instead.

Relevant interfaces: Not interface-specific

Does this change validation behavior? Yes, once each PR lands. This issue itself is about the process.

Additional context
The pack keeps shipping on its own, so nothing on the CDK side waits on this. When a group lands here, the pack stops
evaluating those rules on engines that include it, and deletes them once every supported aws-cdk-lib bundles such an
engine. Taking rules into this repository therefore never leaves the two sets reporting the same finding twice.