fix: attribute user-triggered warnings to the caller via stacklevel

[dhruv-1100]

Overview: What does this pull request change?

Closes #4981.

Warnings that a user's own code triggers are now attributed to the user's line rather than to the line inside Manim where the logger.warning call lives.

Before:

WARNING  Attempted adding some Mobject as a child more than once...   mobject.py:504

After:

WARNING  Attempted adding some Mobject as a child more than once...   my_scene.py:12

Motivation and Explanation: Why and how do your changes improve the library?

Per @nikolajmunk's point on the issue, this is applied only where the action originates in userland — pointing a traceback at Manim's own plumbing would just add noise.

stacklevel is not a constant. It is per-call-site, and I determined each value by inspecting the actual frame chain at warning time rather than assuming:

stacklevel=3

Site	Why
utils/deprecation.py (×2)	the decorator library inserts a wrapper frame between the warning and user code — stacklevel=2 here points at decorator.py, not the user
mobject.py, opengl_mobject.py	the warning lives in the private _insert_submobjects, reached from add, insert and add_to_back (verified all three entry points)
scene.py validate_run_time	called from play / wait / pause / wait_until

stacklevel=2 — warning sits directly in the public method the user calls: Text / MarkupText, BarChart, Surface.set_fill_by_value, Scene.embed (×2).

Deliberately unchanged:

• Scene.replace_in_list — it recurses over submobjects, so no fixed stacklevel is correct.
• Config/environment-driven warnings ("Disabling interactive embed as dry_run is enabled", hashing, file ops, plugins, module loading). These aren't caused by a line of user code.

On the feature freeze: the contributing guide notes Manim is mid-refactor and that new-feature contributions generally aren't being accepted right now, and #4981 carries the new feature label. I've framed this as a fix because the existing warnings report a misleading source location rather than because it adds capability — but if maintainers read it as a feature, I'm happy to park it until the refactor settles.

I used stacklevel rather than stack_info=True; the latter dumps the whole stack into the log, which seemed far noisier than the issue needs. Happy to switch if you'd prefer the full trace.

Further Information and Comments

One existing test needed changing. test_font_warnings asserted against rendered console output, which rich wraps to the terminal width. Because the source location is now the (longer) caller path, the wrap point shifted and split "not in" across two lines:

Font Manim!Manim!Manim! not      test_text_mobject.py:6
in ['.AppleSystemUIFont', ...

The warning itself is unchanged — only the rendered line breaks moved. The test now reads the log record's message via the existing manim_caplog fixture, which isn't width-dependent.

Testing. Added tests/module/utils/test_warning_stacklevel.py, covering both stacklevel=3 shapes (decorator shim and private helper). It asserts the record's pathname, funcName, and the source text of the blamed line rather than a hardcoded line number, so it survives reformatting. Verified it fails on all four cases without the source change.

tests/module/ and tests/opengl/ show no new failures against master (108 pre-existing failures on both, all LaTeX/Typst tests that need a latex binary I don't have locally).

🤖 Generated with Claude Code

[dhruv-1100]

Closing this — I opened it before properly reading the thread above.

@nikolajmunk asked for this one to be left for a first-time contributor to
hand-build. This PR was AI-assisted, so it's exactly what that request was about. Sorry for the
noise - the issue is free as far as I'm concerned.