ignore maybe-initialized warning in map_caster::convert_elements field conv

[alan-rager-skydio]

In map_caster::convert_elements, conv is initialized with a call to ::load, and GCC 13 sees that as a maybe-uninitialized error to call it later:

for (const auto &it : seq) {
    value_conv conv;              // line 332: declared, "uninitialized"
    if (!conv.load(it, convert)) { // line 333: conv.load() initializes conv's internal state
        return false;
    }
    value.push_back(cast_op<Value &&>(std::move(conv)));  // line 336: uses conv
}

By adding ignores around this area, we can avoid the compilation failure.

[rwgk]

Written with the help of Cursor GPT-5.4 Extra High Fast:

---

I tried fairly hard locally to reproduce this before reviewing the warning suppression, using g++ (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0 and Python 3.14.4 (via a SCons/venv setup, plus targeted GCC compiles against tests/*.cpp and a small standalone translation unit).

I was able to trigger other -Wmaybe-uninitialized diagnostics in unrelated areas, but I was not able to reproduce the specific stl.h warning this PR is suppressing.

And that matters here because otherwise we’re guessing about both the root cause and the best fix. Without the exact failing instantiation, it is hard to tell whether this pragma is really the narrowest fix, whether a small code change could avoid the warning, or whether the warning is even coming from the function described in the PR.

Could you please share:

• the full compiler log
• the exact failing compile command
• the exact translation unit / template instantiation that triggers the warning
• whether this happens in pybind11 itself or only in downstream code
• ideally, a minimal standalone reproducer

One more small point: the PR title/description says map_caster::convert_elements, but the patch changes list_caster::convert_elements, so seeing the actual compiler output would also help reconcile that mismatch.