Stdlib decoupling · Step 1: method/trait-impl table in the frozen registry

Part of the stdlib↔compiler decoupling (see docs/discussions/implementation_plans/stdlib_decoupling_protocol.md, §5–§7 step 1). Epic: TBD.

Why. Method resolution (x.exp() → impl Math for f32 → f32$exp) currently walks borrowed AST ImplBlocks in GlobalAstEnv (src/hir/env.rs). Move it into the GID-keyed frozen registry so resolution is a table lookup, not an AST walk.

Scope.

• Extend ImmutableGlobalRegistry (src/registry.rs):
  • methods: FxHashMap<(TypeId /*receiver*/, Symbol /*method*/), FnSig> (inherent + trait methods).
  • trait_impls: FxHashMap<(TypeId /*trait*/, TypeId /*type*/), ImplId> (trait selection / coherence).
• Populate both in build_frozen_registry (src/pipeline.rs), minting the method's FnSig.gid with the same mangling as f32$exp (the existing generic/method mangle in env.rs), keyed by (receiver GID, method name).
• Add resolve_method(recv, method) / resolve_trait_impl(trait, ty) on the registry.

Acceptance. Dual-run parity: for the existing corpus/tests, the registry resolve_method returns the same target the GlobalAstEnv AST walk does (a unit/integration test asserting equality, mirroring the flat-vs-AST differential pattern). No behavior change yet — GlobalAstEnv stays the oracle.

Blocks Step 2 (type checker queries the registry).

Read docs/discussions/implementation_plans/stdlib_decoupling_protocol.md §5–§7, then inspect ImmutableGlobalRegistry in src/registry.rs, build_frozen_registry in src/pipeline.rs, and the existing method walk in src/hir/env.rs. Run the existing corpus/tests and mirror the flat-vs-AST differential pattern so registry resolution matches GlobalAstEnv for methods and trait implementations.