cdk import experience report

### Describe the bug

I just had the displeasure of attempting to use `cdk import`. I want to share my feedback on how unintuitive and unhelpful it is.

I understand that CDK is ultimately a wrapper around CloudFormation, and is bound by its feature set (or lack thereof). Consider this a report against both of them.

First, this command shouldn't even exist. It is forcing an imperative solution atop what is supposed to be a declarative approach. Consequently it does not work well with IaC. One of the most critical parts of an IaC pipeline is that it be idempotent - I must be able to run it repeatedly, with subsequent runs being a no-op. But `cdk import` will fail if the import already happened. So now I need to have some flag to say to do the import or not.

Instead, CloudFormation should support doing an import directly inside the stack template. Essentially, it should work as follows:
- if the resource already exists in the stack, then proceed as usual (update if necessary)
- else if the resource exists in the account, then import it
- else, then create it

With this approach, importing is now fully declarative. I can run my pipeline more than once without special flags and it will succeed. I can even deploy the stack to multiple accounts where only _some_ of them need to do an import.

That aside, within the confines of the current design, there are still issues. For example, the first time I ran it, I had written my import mapping incorrectly. It reported this issue ("Unrecognized resource identifiers in mapping file") but **the command did not fail**.

Furthermore, stack-level tags were not applied to the imported resource. This makes importing into an existing stack even more cumbersome, as we have to go through multiple deployments to unset and reset the stack tags to make everything work. Given that CloudFormation will (sometimes) apply the default aws:cloudformation tags during import, I don't see why it should treat the rest of the tags differently.

### Regression Issue

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

### Last Known Working CDK Library Version

_No response_

### Expected Behavior

see above

### Current Behavior

see above

### Reproduction Steps

see above

### Possible Solution

_No response_

### Additional Information/Context

_No response_

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

2.216.0

### AWS CDK CLI version

2.1029.2

### Node.js Version

v22.19.0

### OS

Alpine

### Language

Python

### Language Version

3.13.7

### Other information

_No response_

The report names the `cdk import` command and CloudFormation, but no source files or tests. Begin by reproducing the import flow with the reported CDK and CLI versions, focusing on invalid mapping handling and stack-tag behavior. Done would require an agreed scope and verified behavior for idempotent import, command failure on invalid mappings, and stack-level tags.

Written by the indexing model from the issue text.