Fix duplicated exception chain output for exceptions without a traceback

[SemTiOne]

When an exception in a chain has no __traceback__ of its own, repr_excinfo() falls back to traceback.format_exception(), which defaults to chain=True and walks the rest of the chain itself, duplicating what pytest's own chain-walking loop then prints again right after.

Fix: pass chain=False to that fallback call.

• Include documentation when adding new features.
• Include new tests or update existing tests when applicable.
• Allow maintainers to push and squash when merging my commits. Please uncheck this if you prefer to squash the commits yourself.
• Closes Exceptions without a traceback print multiple times if chained #8321
• If AI agents were used, they are credited in Co-authored-by commit trailers.
• Create a new changelog file in the changelog directory, with a name like <ISSUE NUMBER>.<TYPE>.rst. See changelog/README.rst for details.
• Add yourself to AUTHORS in alphabetical order.

[SemTiOne]

Hello @RonnyPfannschmidt, I would like you to take a look at this PR when you have a moment please. Let me know if you have any feedback. Thank you for your time 🙏

[RonnyPfannschmidt]

am i understanding it correct that this bandaids our lack of proper walking with disabling chaining to prevent running out of it

i think this works as a initial fix but needs a followup with more substantial work in excinfo wrt handling more detailed traces

[SemTiOne]

Yep, I agree this is a bandaid.

I wonder if we should make the traceback optional in ExceptionInfo? Or, perhaps we add a lightweight chain member representation? With repr_excinfo as the one and only chain walker, no native format_exception fallback is needed for traceback-less members. The ExceptionGroup fallback stays native for now and we no longer need the chain=False workaround. What do you think @RonnyPfannschmidt?

[RonnyPfannschmidt]

I haven't actually ever dubbed to deep into that domain (most exceptions I have to handle are simple

So I'm not familiar with the developer experience and I'm of the opinion that someone that deals with tricky exceptions is more qualified to answer this

Perhaps @Zach-HD can chime in