feat(php): map transparent proxies to real classes

[sidux]

Why

Generated runtime proxies often appear in configuration while their useful declarations live on the parent class. Navigating into cache artifacts is noisy, and treating proxy and real names as unrelated splits references and member metadata. The mapping must stay opt-in and generic because proxy layouts and marker contracts vary by package.

Summary

• add configurable proxy paths and marker-interface rules
• parse generated proxy metadata statically without loading or executing cache files
• map resource navigation, class references, member references, and declaration lenses back to the real class
• rebuild affected resource symbol maps when proxy configuration or generated files change

Dependency

• stacked on feat(navigation): navigate PHP symbols in YAML and XML #394 because proxy names are discovered through generic YAML/XML resource navigation

Validation

• cargo clippy --all-targets -- -D warnings
• cargo test: 14,117 passed; 12 ignored

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 90.65421% with 40 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/proxy_metadata.rs	93.39%	21 Missing ⚠️
src/indexing/watch.rs	52.38%	10 Missing ⚠️
src/resource_navigation.rs	76.31%	9 Missing ⚠️

📢 Thoughts on this report? Let us know!

[AJenbo]

Could you provide a sample setup where I can see how the code this acts on looks

[sidux]

Good question. The intent was to handle generated proxies in general: ProxyManager (friendsofphp/proxy-manager-lts) subclasses such as the ones openclassrooms/service-proxy creates, and Doctrine's Proxies\__CG__ entities. The idea was that when metadata named the generated class, navigation and references would land on the real one.

Building the sample showed that nothing in the project actually names those classes. service-proxy keeps the real class on the service definition and creates the proxy at runtime through a factory, and Doctrine mappings always name the real entity. The generated names only exist at runtime.

What we really needed was the relation between those services and their events, and #402 covers that from the real classes: it reads the final wiring from the generated container, and the #[Event] / #[Listen] attributes through configurable rules in .phpantom.toml. So this mapping has nothing left to do, and I'll close this PR. Thanks for asking for a concrete case.