[kroplabeskidu]

Description

Item 13 from #6159. The STL casters accept some builtin iterables by matching tp_name (map, zip, dict_keys, dict_values, dict_items). A user class with one of those names passes the check even if it isn't iterable. Release builds then raise TypeError: 'map' object is not iterable from inside the caster, which stops overload resolution. The review reports that debug builds hit the isinstance<iterable> assert and abort; I only ran this test on a release build before the fix.

A name match now also requires the object to be iterable, so the caster returns false and the next overload gets a chance.

The review suggests rejecting heap types. I used an iterability check because it doesn't rely on how PyPy and GraalPy flag these types. As a result, an iterable user class named map is still accepted, same as before.

Suggested changelog entry:

• STL casters now reject non-iterable user classes named like builtin iterables, instead of raising during overload resolution.