pv extract:code: binding function: Type::method never resolves; bare method names are ambiguous across impls #4521

Found while binding paiml/rust-mdipierro-nlib (GH-1) at aprender 1274d04 (pv 0.70.0 (1274d040d)).

Repro

// src/lib.rs of crate `demo`
pub mod random;
// src/random.rs
pub struct Lcg;
impl Lcg { pub fn next_f64(&mut self) -> f64 { 0.0 } }
pub struct Mt19937;
impl Mt19937 { pub fn next_f64(&mut self) -> f64 { 1.0 } }

# contracts/binding.yaml (any contract with equation `uniform`)
target_crate: demo
bindings:
- contract: x-v1.yaml
  equation: uniform
  module_path: demo::random
  function: Mt19937::next_f64
  status: implemented

pv lint contracts/ --gate shapes then reports "symbols_unresolved": 1.

What happens

• extract/code.rs resolve_in_root → find_item(&module.items, function) compares f.sig.ident == name, so Type::method can never match. The no fn ... (free or in an impl) reason is not printed anywhere in the --gate shapes output: only the count shows, so the user has to guess which bindings failed.
• Writing the bare name next_f64 does resolve, but find_item returns the FIRST impl that has it (here Lcg::next_f64), so the symbol IRI points at the wrong method. A binding can't pick between two impls in the same module.

Expected

1. function: Type::method resolves to the method in impl Type (and impl Trait for Type).
2. The gate output lists each unresolved (contract, equation, module_path::function, reason), not just the count.

In rust-mdipierro-nlib, 16 of 96 bindings were written Type::method, so they were silently unresolved. We moved them to bare names; the next_f64 ambiguity is recorded in docs/ontology-conformance.md.