possible cross-ingot symbol collision

### Investigate cross-ingot symbol collisions for lazily lowered dependency functions

`Monomorphizer::compute_ambiguous_bases` runs once during construction from the initial template
set, but `ensure_template` can later lower additional dependency functions on demand and append them
to `self.templates` without recomputing `ambiguous_bases`.

Relevant paths:
- `crates/mir/src/monomorphize.rs`: `compute_ambiguous_bases` is called once in `new`.
- `crates/mir/src/monomorphize.rs`: `ensure_template` can lazily lower a `Func` from another
module/ingot and push it into `self.templates`.
- `crates/mir/src/monomorphize.rs`: `mangled_name` only adds a module qualifier when the base name
is present in `ambiguous_bases`.

Potential impact:
- A user function present in the initial template set and a lazily lowered dependency function can
end up with the same raw symbol when they share a base name but no ambiguity was recorded up
front.
- That would affect any later logic that treats `symbol_name` as globally unique inside a MIR
module, including codegen/linking passes keyed only by strings.

This needs a focused repro. If confirmed, the fix should be in the general symbol-generation path,
not in the Yul helper linker.

Start in crates/mir/src/monomorphize.rs by tracing compute_ambiguous_bases from new, then follow ensure_template and mangled_name. Build a focused case with an initial user function and a lazily lowered dependency sharing a base name, and check whether their raw symbols collide. Done means the collision is confirmed or ruled out; if confirmed, address it in the general symbol-generation path rather than the Yul helper linker.

Written by the indexing model from the issue text.