Name-keyed registry cannot disambiguate a local plain class from a foreign reactive class with the same name

[nank1ro]

Problem

The cross-file registry is keyed by simple class name. When a file locally declares a plain class Foo AND holds (e.g. via an inherited super.thing typed in the base file's scope) a DIFFERENT, @SolidState-bearing Foo from another library, only one behavior is expressible:

• Registering the foreign Foo wrongly rewrites reads on the LOCAL plain class (non-compiling .value — caught and blocked in fix(solid_generator): seed bare super.x constructor params syntactically #109's review), so
• the local declaration now shadows registration entirely — which means the genuinely reactive foreign read (thing.label) stays silently un-lowered. Documented trade-off in the cross_file_super_param_one_hop_local_shadow fixture; same family as the Cross-file @SolidState reads through constructor-injected holders are silently un-lowered #104 decoy limitation.

Fix

Qualify registry entries by their origin library and disambiguate at rewrite time:

1. Registry entries become name → [(originUri, scalar/collection fields)] — the one-hop threading already tracks origin URIs; stop dropping shadowed foreign entries, store them qualified.
2. In the value rewriter's tier-1 (resolved staticType) path, compare the receiver's element library URI against the entry's origin — rewrite only on a match. thing (staticType = base file's Foo) lowers; f (staticType = local Foo) doesn't. Precise, not name-based.
3. AST-only tiers (unresolved contexts) cannot know the library: under any same-name ambiguity (multiple entries, or an entry + a local declaration) keep today's conservative no-rewrite. The change can only ADD correct rewrites where real resolution exists — never introduce a wrong one.

This also narrows SPEC §4.9's documented name-collision caveat wherever tier-1 resolution applies.