`terraform workspace new -lock=false` doesn't work as advertised

### Terraform Version

```shell
Terraform v1.9.8
on linux_amd64
+ provider registry.terraform.io/cloudposse/utils v1.24.0
+ provider registry.terraform.io/hashicorp/aws v5.55.0
+ provider registry.terraform.io/hashicorp/external v2.3.3
+ provider registry.terraform.io/hashicorp/local v2.5.1
```

### Terraform Configuration Files

`backend.tf.json`:
```json
{
"terraform": {
"backend": {
"s3": {
"assume_role": {
"role_arn": "arn:aws:iam::123456789012:role/sl-automation-terraform"
},
"bucket": "sl-atmos-tfstate-123456789012",
"dynamodb_table": "sl-atmos-tfstate-lock-123456789012",
"encrypt": true,
"key": "terraform.tfstate",
"region": "eu-central-1",
"workspace_key_prefix": "wms//xe02/sandbox"
}
}
}
}
```

### Debug Output

-

### Expected Behavior

`terraform workspace new -lock=false foo` should not try to lock the state.

### Actual Behavior

`terraform workspace new -lock=false foo` fails if a DynamoDB lock is held by some other process.

### Steps to Reproduce

There is probably an easier way to reproduce this but this is more or less what happened:

On one host:
1. Use a non-`default` workspace (let's call it `foo`)
2. Start some long-running `apply`
3. Abort it in the middle by killing the process or just pressing Ctrl+C twice (the DynamoDB lock is not cleared)

On another host:
1. Using the `default` workspace: Try to clean up the mess via `terraform force-unlock $uuid` (result: `Failed to unlock state: failed to retrieve lock info for lock ID "8ac7bbfc-c1b4-615d-38d7-f7ba634aa4bb": unexpected end of JSON input` because the wrong `LockID` is looked up according to the debug log)
2. Try to switch to a properly named workspace via `terraform workspace new foo`: This will fail due to the existing lock
3. Discover the `-lock=file` option and try it with `terraform workspace new -lock=false foo`: This will fail, too

### Additional Context

_No response_

### References

- cloudposse/atmos#800

Start at the `terraform workspace new` command path and reproduce the behavior with the S3 backend configuration shown, including a held DynamoDB lock. Compare `-lock=false` with the normal workspace-creation flow and the `force-unlock` lookup; done means creating a workspace with `-lock=false` does not attempt to acquire the existing state lock, with regression coverage for the reported case.

Written by the indexing model from the issue text.