fix(logs): emit root ARN in resource policy to prevent CloudFormation drift

[nithinnnv]

Issue # (if applicable)

Closes #37797.

Summary

• convertArnPrincipalToAccountId in aws-logs/lib/log-group.ts was emitting bare account IDs (e.g. "211125612616") as the Principal.AWS value in CloudWatch Logs resource policies when grantRead() or addToResourcePolicy() is called with a cross-account principal.
• CloudFormation normalizes bare account IDs to the canonical root ARN form (arn:aws:iam::211125612616:root) on the deployed resource. This mismatch causes drift detection to permanently flag every stack using these methods with a cross-account principal as DRIFTED on every evaluation cycle.
• Fix emits the root ARN form directly so the synthesized template matches what CloudFormation stores, making drift detection a no-op. Both forms are semantically identical to AWS IAM.

Test plan

• Updated unit tests in aws-logs/test/loggroup.test.ts to assert root ARN format
• Added regression test grantRead with cross-account role emits root ARN to prevent CloudFormation drift
• Updated integ.loggroup-grantread.ts to include a cross-account ArnPrincipal case and regenerated snapshot — LogGroup2's resource policy shows "AWS":"arn:aws:iam::123456789012:root"

[nithinnnv]

@aws-cdk/aws-cdk-owners — gentle ping! Happy to address any feedback.

[abidhasan-aws]

Hi @nithinnnv,

As @krantboy reported #37797 (comment), CloudWatch Logs rejects ARN-format principals:

"Principal section of policy contains ARN instead of account ID: arn:aws:iam::<account>:root"
(CloudWatchLogs, Status Code: 400, HandlerErrorCode: InvalidRequest)

I personally verified this with a bare CFN template (no CDK) — the root ARN is rejected, the bare account ID is accepted. But the bare ID is normalized to the ARN form on the resource side. Later when we deploy the same stack again, CloudFormation checks the resource state (normalized ARN) vs the template (bare account ID) and flags it as drift.

I further discuss in the issue: #37797 (comment)