Fix Trac #6259: recognize possible use of embedded member addresses

[KiritoYG]

Passing an embedded list node to a retaining function currently leaves its containing allocation classified as unused, producing the C memory-leak false positive in Trac #6259. A following unrelated statement exposes the issue; a final unknown call can already suppress it through a separate fallback.

Record possible usage of the allocation when a call receives the address of one of its embedded members. Walk member/type information to find the owning raw-pointer variable, stopping at a separately pointed-to object. Require the address to be the complete argument value, optionally through pointer casts. Keep allocation/deallocation history intact, and respect leak-ignore and pure-function configuration.

The C++ path accepts only known scalar/pointer member types and rejects static/reference storage and overloaded member access. Class, enum and unknown C++ terminal member types are conservatively excluded to avoid assuming built-in operator& semantics. This extends possible-use handling; it does not prove that an unknown callee retains or frees the allocation. Existing --check-library configuration information remains appropriate for unmodeled calls.

Validation on Windows with Clang 22.1.8 and CMake/Ninja (Debug, PCH disabled, serial build):

• Original-fragment and complete ownership regressions fail against unchanged production code, then pass with the fix.
• All 5,303 native unit tests pass, with 351 existing TODO assertions. Nine new cases cover member-address variants, nested storage, true leaks, scalar derivations, pure/leak-ignore functions, C++ storage boundaries, double free and allocation mismatch.
• Sixteen baseline/final CLI runs across unix32/unix64 confirm the original fragment and two complete C fixtures are fixed while three true-leak controls remain. Two additional default-analysis runs reproduce and resolve the independently written intrusive-list case.
• The three complete C fixtures pass Clang C11 syntax checking. git diff --check passes. GUI and non-Windows CI have not been run locally.

Please assign this work to KiritoYG if needed and consider it under the published $10 bounty schedule, subject to acceptance and the required ticket closure. Please confirm eligibility and the supported settlement route; GitHub Sponsors is available if accepted. No award or payment is being claimed.

[KiritoYG]

The Windows 2025 release job failed in test_addon_no_artifacts[False] during the -j2 CLI pass: the expected MISRA 5.8 diagnostic was present, but whole1.c.5396.dump remained. The same test passed in the earlier serial CLI pass; native tests and all 515 serial CLI tests passed. Failed job log.

The two inputs contain only global declarations, so the changed function-call/member-address path is not exercised. Dump creation/removal and this test are unchanged by the PR. Five repetitions with the untouched baseline and five with the patch passed locally with -j2, the expected diagnostic, and no leftover files. Those local builds are MinGW Debug, so they do not establish the exact cause on the hosted MSVC Release runner.

Could a maintainer rerun this Windows job once? The rerun API requires repository administrator rights. I have left the cleanup assertion and source unchanged rather than masking this intermittent failure.