PHP: use-alias pointing outside the corpus + one same-short-named in-corpus class mints a wrong INFERRED edge (design risk 6, measured)

[filipechagas]

Confirmed during release verification of the Graphify-Labs#1682 feature branch (see /tmp/probe7_changelog_claims.py scenario): a property typed via use Vendor\Sdk\Client; (class outside the corpus) with exactly one unrelated in-corpus App\Local\Client mints a wrong INFERRED 0.8 calls edge. Base commit 4e7e6b1: no edge — so this is a new false positive introduced by receiver-typed resolution, in the corner the spec explicitly accepted and documented (issue #1 Out of Scope: identical exposure exists in the Java resolver today).

Named in the 0.9.34 changelog as a known limitation. The documented upgrade path is use-import-map awareness (the C# CsharpNameResolver pattern).

Refs: spec #1, design open-risk 6, 0.9.34 changelog entry.

[filipechagas]

Triaged. The fix path is spec #18 (PHP use-import-map awareness, following the CsharpNameResolver pattern), decomposed into #19 -> #20 -> #21 -> #22 -> #23. #21 is the ticket that closes this issue (decisive refusal when a use alias claims the short name); #22/#23 are the positive-binding recall follow-up and must ship together. The canonical repro fixture (previously only in /tmp/probe7_changelog_claims.py scenario 10) is preserved in #18's body. Removing needs-triage; this issue stays open until #21 merges with gate evidence.

[filipechagas]

Fixed by #21 / PR #32 (merge commit cec9cdd). The canonical repro (probe7 scenario 10, preserved in spec #18) now yields no edge; the fully-qualified-annotation and namespace-relative variants of the same false-edge class are fixed in the same pass. Gate evidence on #21. The positive-binding upgrade (correctly resolving in-corpus aliases among duplicate short names) remains tracked as #22 + #23, which must ship together.