fix: Add Control Tower 4.0 compatibility

[pavanvooturi31]

Summary

Adds Control Tower 4.0 compatibility to SRA. CT 4.0 removed several StackSets that SRA relied on for account discovery and configuration.

Changes

• Account Discovery: Falls back to CT Landing Zone API (ListLandingZones/GetLandingZone) when legacy StackSets (AWSControlTowerBP-BASELINE-CONFIG, AWSControlTowerBP-BASELINE-CLOUDWATCH) do not exist. Further falls back to Organizations API name-based matching.
• Config Delivery Bucket: Discovers bucket name from AWSControlTowerBP-CONFIG-CENTRAL-S3-BUCKET StackSet (CT 4.0 uses random suffix). Falls back to legacy aws-controltower-logs-{acct}-{region} pattern. Stored as SSM parameter (CT-only, gated by CONTROL_TOWER == true).
• Config Aggregator: Gracefully handles missing aggregator (NoSuchConfigurationAggregatorException) since CT 4.0 uses org-level aggregator. Added pUpdateConfigAggregator toggle and flexible aggregator name.
• Config Service-Linked Role: Added pCreateConfigServiceLinkedRole toggle (CT 4.0 may already have it).
• Bedrock solutions: Same StackSet fallback pattern applied to bedrock_org and bedrock_guardrails.

Testing

Deployed and validated in CT 4.0 environment (us-east-2). Config delivery channel correctly uses CT 4.0 bucket name. Config Aggregator update gracefully skipped.

Backward Compatibility

All changes use try/catch with fallback to legacy behavior. Existing CT 3.x deployments are unaffected. Non-CT environments are unaffected (config-delivery-bucket-name SSM parameter only created when CONTROL_TOWER=true).

[cyphronix]

Reviewed, tested, and approved.