Debugging generated files broken with C++ path-mapping

### Description of the bug:

Currently when using C++ path mapping for CppCompile actions, the final binary containing those path mapped files contains generated files at the path-mapped locations. These locations don't exist outside of the build action, so at runtime of the binary, if you attempt to fetch debug info, it will not work in today's common debugging workflows since the path is invalid.

### Which category does this issue belong to?

_No response_

### What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

In this project, with a recent version of clang installed: [repro.zip](https://github.com/user-attachments/files/18973138/repro.zip)

First you can see the good behavior with:

```
bazel build :foo
```

You can check the binary already for the paths:

```
% llvm-dwarfdump bazel-bin/foo | grep generated.cpp
DW_AT_name ("bazel-out/k8-dbg/bin/generated.cpp")
DW_AT_decl_file ("./bazel-out/k8-dbg/bin/generated.cpp")
DW_AT_decl_file ("./bazel-out/k8-dbg/bin/generated.cpp")
DW_AT_linkage_name ("_GLOBAL__sub_I_generated.cpp")
```

And you can validate that path exists:

```
% cat ./bazel-out/k8-dbg/bin/generated.cpp
#include

void foo() {
std::cout << "from generated file" << std::endl;
}
```

If you want to validate this in the debugger you can run the binary and see that you correctly get source mapping:

```
% lldb bazel-bin/foo
(lldb) target create "bazel-bin/foo"
Current executable set to '/tmp/repro/bazel-bin/foo' (x86_64).
(lldb) b foo
Breakpoint 1: where = foo`foo() + 4 at generated.cpp:4:13, address = 0x00000000000019e4
(lldb) r
Process 10599 launched: '/tmp/repro/bazel-bin/foo' (x86_64)
Process 10599 stopped
* thread #1, name = 'foo', stop reason = breakpoint 1.1
frame #0: 0x00005555555559e4 foo`foo() at generated.cpp:4:13
1 #include
2
3 void foo() {
-> 4 std::cout << "from generated file" << std::endl;
5 }
```

Now to reproduce the path stripped / bad behavior:

```
bazel build :foo --config=strip
```

You can see the path embedded in the debug info does not exist:

```
% llvm dwarfdump bazel-bin/foo | grep generated.cpp
DW_AT_name ("bazel-out/cfg/bin/generated.cpp")
DW_AT_decl_file ("./bazel-out/cfg/bin/generated.cpp")
DW_AT_decl_file ("./bazel-out/cfg/bin/generated.cpp")
DW_AT_linkage_name ("_GLOBAL__sub_I_generated.cpp")
% cat ./bazel-out/cfg/bin/generated.cpp
cat: ./bazel-out/cfg/bin/generated.cpp: No such file or directory
```

And when you attempt to debug you won't get valid source maps:

```
% lldb bazel-bin/foo
(lldb) target create "bazel-bin/foo"
Current executable set to '/tmp/repro/bazel-bin/foo' (x86_64).
(lldb) b foo
Breakpoint 1: where = foo`foo() + 4 at generated.cpp:4:13, address = 0x00000000000019e4
(lldb) r
Process 11771 launched: '/tmp/repro/bazel-bin/foo' (x86_64)
Process 11771 stopped
* thread #1, name = 'foo', stop reason = breakpoint 1.1
frame #0: 0x00005555555559e4 foo`foo() at generated.cpp:4:13
```

### Which operating system are you running Bazel on?

linux x86_64

### What is the output of `bazel info release`?

723872c07f95a8cfc72d3de6ad0892e2d1cb668c

### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.

_No response_

### What's the output of `git remote get-url origin; git rev-parse HEAD` ?

```text

```

### If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

_No response_

### Have you found anything relevant by searching the web?

_No response_

### Any other information, logs, or outputs that you want to share?

_No response_

Start with repro.zip and compare the debug information from `bazel build :foo` and `bazel build :foo --config=strip` using `llvm-dwarfdump`. Trace how C++ path mapping is applied to CppCompile actions, then use the shown LLDB workflow to verify that generated.cpp resolves to an existing source path in the stripped configuration.

Written by the indexing model from the issue text.