Share Overload signatures behind Arc to avoid deep-copying on clone

[alexander-beedie]

Summary

• Profiling¹ showed a lot of Type value churn; one of the largest drivers looked like cloning Overload, which deep-copies its Vec1<OverloadType> signature list. This happens a lot on read-only paths where nothing is mutated and the copy isn't necessary.

• The optimisation is just to wrap Overload.signatures with Arc (much likeTArgs does). The top contributor (OverloadType::to_vec, ~23% of clone samples) then disappears from profiling.

• Included a dedicated profiling entry in the Cargo.toml (basically "inherit release but keep symbols") for convenience, assuming anyone else is doing dedicated profiling builds - can remove if unwanted?

I have a few other possible optimisations in mind, but want to keep any PRs single-focused/tight 👍

Test Plan

Ran the test suite; all tests show identical before/after results.
(Expected, as no type-checking logic changed).

Speedup

Overload-heavy code is what benefits; numpy (5.7% faster) and pydantic (~2.7% faster) stand out. Showing the single-threaded j1 speedup here, for clarity (mt scores are noisier as the gain is small):

Package	LOC	old (secs)	new (secs)	Δ%
numpy	313k	20.14 ± 0.06	19.00 ± 0.28	−5.7%
pydantic	46k	0.444 ± 0.006	0.432 ± 0.004	−2.7%
pandas	658k	5.40 ± 0.05	5.31 ± 0.11	−1.8%
scipy	553k	3.30 ± 0.02	3.25 ± 0.02	−1.5%
scikit-learn	381k	2.16 ± 0.02	2.13 ± 0.01	−1.4%

Footnotes

1. On Apple Silicon M3 Max, with --threads 1 to help minimise noise. ↩

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅