Fix owned iterator arrow false positives

[KiritoYG]

Default-constructed iterators that return &ownedMember from operator-> can be used to initialize their storage, but the complete example in Trac #6572, comment 7 currently produces eraseDereference, uninitvar, and uninitStructMember. This change makes that complete example diagnostic-free.

The iterator check recognizes an initial arrow access whose visible implementations directly return owned storage. Iterator classification, unary dereference checking, and post-erase invalidation remain intact. Unknown bodies, inherited/proxy arrows and overloaded address-of stay conservative.

The initialization analysis additionally recognizes standalone writes through a narrowly proven accessor: a local receiver has one plain owned member with one primitive scalar, and every arrow overload returns the same member's built-in address. This lets the existing flow distinguish initialization from read-modify-write without a generic non-const-call bailout. Nested expression writes, alias bindings, complex layouts and writes to captured outer objects in deferred lambdas retain existing handling.

Validation:

• Native regressions reproduce the original diagnostics on unchanged production and pass after the fixes.
• Windows Clang 22.1.8: 5,303 native tests pass, with 351 existing TODO assertions.
• Independent Linux GCC 11.4.0 verification, with warnings treated as errors: 5,365 native tests pass (360 existing TODO assertions), plus 199 focused initialization/STL tests. The helper differs from this source only by its isolated verification workflow.
• 71 syntax-valid CLI fixtures cover the original example, true reads, conditional writes, overload/layout boundaries and deferred execution; 55 explicit clean/detection assertions pass, with 16 unsupported or pre-existing cases recorded separately.
• Uncrustify 0.80.1, git diff --check, and a file-scoped equivalent of the project's self-check pass.

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