Fix: `Axes` submobject colors are not being set properly

[ishu9bansal]

Overview: What does this pull request change?

Mitigates the issue, that setting the color of a DecimalNumber object to BLACK will actually render a number with WHITE fill. Further details about the issue can be found on the issue itself #3633

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

Root Cause: The method get_fill_colors treats the RGBA value [0, 0, 0, 0] (fully transparent black) as equivalent to None. As a result, during the initialization of certain objects, the fill_color is effectively set to None, while in other cases it defaults to WHITE. Therefore, when we explicitly set fill_color to BLACK, it ends up being interpreted as WHITE due to this inconsistency.

The code that interprets [0,0,0,0] as None can be found here: https://github.com/ManimCommunity/manim/blob/3377f6c1f69fa2d34628758e163fcaf9d91aa2fe/manim/mobject/types/vectorized_mobject.py#L566-L573

Mitigation: Initialize the VMobject with a fill_opacity value from the input parameters (which defaults to 1 for a DecimalNumber object). This ensures the fill_color is applied correctly. By default, fill_opacity is 0 for a VMobject, which causes the internal fill_color to be [0, 0, 0, 0] (interpreted as None) even when BLACK is specified. Setting fill_opacity = 1 ensures that the fill_color is preserved as BLACK as intended.

Note: This is a workaround. The underlying issue is that a fill_color of BLACK is effectively ignored when fill_opacity = 0, due to its [0, 0, 0, 0] representation. We should investigate whether this behavior is expected or a design flaw, and address it in a separate issue.

Reviewer Checklist

• [ ] The PR title is descriptive enough for the changelog, and the PR is labeled correctly
• [ ] If applicable: newly added non-private functions and classes have a docstring including a short summary and a PARAMETERS section
• [ ] If applicable: newly added functions and classes are tested