efs: L2 construct creates a default file system policy that prevents mounting

### Describe the bug

When creating an EFS file system using the CDK L2 construct `aws_cdk.aws_efs.FileSystem`, the resulting file system cannot be mounted from Kubernetes pods using the EFS CSI driver. The mount operation fails with `access denied by server` errors. After investigation, the root cause appears to be that the L2 construct automatically attaches a restrictive file system policy, even though the documentation states that `file_system_policy` should be `NONE` by default.

### Regression Issue

- [ ] Select this option if this issue appears to be a regression.

### Last Known Working CDK Library Version

_No response_

### Expected Behavior

- Documentation states that `file_system_policy` should be `NONE` by default.
- If no policy is specified, the file system should be mountable without restrictions.
- Alternatively, if a default policy is applied, it should include `elasticfilesystem:ClientMount` so that mounting works correctly.

### Current Behavior

Mount fails with errors such as:

```
rpc error: code = Internal desc = Could not mount "fs-xxxx450b:/"
mount.nfs4: access denied by server while mounting 127.0.0.1:/
```
Additional warnings from `efs-utils` about configuration items appear, but the critical issue is the access denial.

### Reproduction Steps

1. Create an EFS file system using the L2 construct as per documentation:
```
efs_file_system = efs.FileSystem(
self, "MyEfsFileSystem",
vpc=vpc,
performance_mode=efs.PerformanceMode.GENERAL_PURPOSE,
throughput_mode=efs.ThroughputMode.BURSTING,
encrypted=True,
lifecycle_policy=efs.LifecyclePolicy.AFTER_30_DAYS
)
```
2. Deploy and attempt to mount the EFS file system from a Kubernetes pod via the EFS CSI driver.

### Possible Solution

Please update the L2 construct so that:

- No policy is created by default (consistent with documentation), OR

- The default policy includes `elasticfilesystem:ClientMount` to allow mounting.

This will ensure that EFS file systems created via CDK L2 can be mounted successfully without requiring manual intervention.

### Additional Information/Context

Root Cause

- The L2 construct automatically creates a file system policy like the following:

`{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "AWS": "*" },
"Action": [
"elasticfilesystem:ClientRootAccess",
"elasticfilesystem:ClientWrite"
],
"Resource": "arn:aws:elasticfilesystem:region-code:ACCOUNT_ID:file-system/fs-XXXX",
"Condition": {
"Bool": { "elasticfilesystem:AccessedViaMountTarget": "true" }
}
}
]
}
`

- This policy **does not include** `elasticfilesystem:ClientMount`, which is required for mounting. As a result, the CSI driver cannot mount the file system.

### AWS CDK Library version (aws-cdk-lib)

2.225.0

### AWS CDK CLI version

2.1033.0 (build 1ec3310)

### Node.js Version

NA

### OS

macOS

### Language

Python

### Language Version

Python 3.13.1

### Other information

- Documentation states that `file_system_policy` should be `NONE` by default.
- If no policy is specified, the file system should be mountable without restrictions.
- Alternatively, if a default policy is applied, it should include `elasticfilesystem:ClientMount` so that mounting works correctly.

Start at the aws_cdk.aws_efs.FileSystem L2 construct and inspect how the default file_system_policy is generated, comparing it with the documented NONE default and the reported policy actions. Confirm that the resulting policy permits EFS CSI mounting, and ensure the behavior matches one of the stated expected outcomes.

Written by the indexing model from the issue text.