fix(cdk-aspects): declare aws-cdk-lib and constructs as peerDependencies

[toddhainsworth]

Summary

Moves aws-cdk-lib and constructs from dependencies to peerDependencies in @aligent/cdk-aspects, matching the convention used by every other @aligent/cdk-* construct package.

Why

As regular dependencies, a consumer whose own aws-cdk-lib resolves to a different version ends up with two copies in the tree — the app's, and a nested one under @aligent/cdk-aspects. The aspects' node instanceof CfnResource guard compares against the nested copy's class, while the constructs being visited are instances of the app's copy. Different class objects → instanceof is always false → visit() returns early for every node.

Result: aspects silently become a no-op — no prefixes, no defaults, no checks — with a valid-but-untouched synth and no error or warning. Declaring them as peers guarantees a single shared instance with the consumer.

Changes

• packages/cdk-aspects/package.json — aws-cdk-lib (^2.113.0) and constructs (^10.5.0) moved to peerDependencies. Range widened from the old ^2.257.0 pin to the repo's dominant peer range; a peer should accept a broad span of consumer CDK versions, and the aspects only touch the stable CfnResource API.
• yarn.lock — reflects the move; no duplicate aws-cdk-lib locator introduced.
• .changeset/ — patch bump.

Verification

• yarn nx build/test/lint cdk-aspects — all pass (55 tests green).
• yarn changeset:status — single patch bump for @aligent/cdk-aspects.
• Lockfile inspected: one aws-cdk-lib locator, no nested duplicate.

Notes

Scoped to the peer-dependency packaging fix only. The separate ResourcePrefixAspect token/empty-base-name regression reported alongside this is already fixed on main by MI-323 (0.6.3) and is not part of this PR.

[crispy101]

LGTM