[compiler-rt][tysan][libc++] False positives with std::function callable storage

# `std::function`
#### Flags: `-stdlib=libc++ -fsanitize=type -O0` or `-stdlib=libc++ -fsanitize=type -O1`
#### Compiler: x86-64 clang 22.1.0
#### Link: https://godbolt.org/z/PYT6Mob5Y
#### Code:
```.cpp
#include

std::function f = [](){};

int main() {
f();
}
```
#### Logs:
```
==1==ERROR: TypeSanitizer: type-aliasing-violation on address 0x648731af5f30 (pc 0x648731199f57 bp 0x7ffcbb8ccd10 sp 0x7ffcbb8ccca0 tid 1)
WRITE of size 8 at 0x648731af5f30 with type vtable pointer accesses an existing object of type std::__1::function
#0 0x648731199f56 (/app/output.s+0x37f56)

==1==ERROR: TypeSanitizer: type-aliasing-violation on address 0x648731af5f30 (pc 0x648731199360 bp 0x7ffcbb8ccd40 sp 0x7ffcbb8cccd0 tid 1)
WRITE of size 8 at 0x648731af5f30 with type vtable pointer accesses an existing object of type std::__1::function
#0 0x64873119935f (/app/output.s+0x3735f)
...
```
#### Explanation:
libc++ `std::function` is likely doing placement-new vtable.

Reproduce the report using the Godbolt link with libc++, -fsanitize=type, and -O0 or -O1, then inspect the libc++ std::function callable-storage path involved in the placement-new operation. Compare the TypeSanitizer diagnostics with the storage behavior; the issue is done when this valid example no longer produces false-positive type-aliasing violations.

Written by the indexing model from the issue text.