[material_ui] Let TabBarThemeData.indicator satisfy the indicatorWeight assert

[m1roxx]

TabBar and TabBar.secondary asserted indicator != null || (indicatorWeight > 0.0) in their
constructors. A constructor has no BuildContext, so that check can only see the widget-level
indicator and is blind to TabBarThemeData.indicator. As a result, an app that supplies its
indicator app-wide through the theme cannot also pass indicatorWeight: 0 to suppress the default
underline thickness — the only workarounds are an epsilon weight, or moving the indicator to the
widget, which then overrides the themed one.

This contradicts the documented behavior of indicatorWeight, which already states:

If indicator is specified or provided from TabBarThemeData, this property is ignored.

This PR moves the check to _TabBarState._getIndicator, which runs after both the widget-level and
the theme-level indicator have been ruled out, so it now fires only when the TabBar actually draws
its default underline indicator. This matches the direction suggested by @dkwingsmt in
flutter/flutter#188837 (comment).

The indicatorWeight doc comment is updated to describe the relaxed constraint.

Fixes flutter/flutter#188837

Tests

Two tests are added to packages/material_ui/test/tabs_test.dart; both fail before this change:

• TabBar.indicatorWeight can be zero when the indicator comes from the theme — a regression test
  covering both TabBar and TabBar.secondary, verifying that the widget builds and paints the
  themed indicator.
• TabBar asserts when indicatorWeight is zero and no indicator is provided — verifies the check is
  still enforced when the TabBar falls back to its default underline indicator.

material_ui is a batch-release package, so the changelog entry is a new file under
pending_changelogs/ with version: patch rather than a direct CHANGELOG.md/pubspec.yaml edit.

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I followed the version and CHANGELOG instructions, using semantic versioning and the repository CHANGELOG style, or I have commented below to indicate which documented exception this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩²

[gemini-code-assist]

Code Review

This pull request removes the constructor assertion requiring indicatorWeight to be greater than zero when an indicator is provided by the theme, deferring the assertion to the state build phase when the default underline indicator is actually used. The review feedback suggests using DefaultTabController in the newly added tests to manage the controller lifecycle more safely and prevent potential ticker leaks.

[gemini-code-assist]

Using DefaultTabController is more idiomatic and safer here, as it automatically manages the lifecycle of the TabController and avoids potential memory or ticker leaks in tests.

    Widget buildTabBar({bool secondaryTabBar = false}) {
      return boilerplate(
        useMaterial3: false,
        tabBarTheme: tabBarTheme,
        child: DefaultTabController(
          length: tabs.length,
          child: Container(
            alignment: Alignment.topLeft,
            child: secondaryTabBar
                ? TabBar.secondary(indicatorWeight: 0.0, tabs: tabs)
                : TabBar(indicatorWeight: 0.0, tabs: tabs),
          ),
        ),
      );
    }

[gemini-code-assist]

Using DefaultTabController here avoids manually creating a TabController and ensures proper disposal, preventing potential ticker leaks in the test.

Suggested change

	final tabs = List<Widget>.generate(2, (int index) => Tab(text: 'Tab $index'));
	final TabController controller = createTabController(
	vsync: const TestVSync(),
	length: tabs.length,
	);
	await tester.pumpWidget(
	boilerplate(
	child: TabBar(indicatorWeight: 0.0, controller: controller, tabs: tabs),
	),
	);
	final tabs = List<Widget>.generate(2, (int index) => Tab(text: 'Tab $index'));
	await tester.pumpWidget(
	boilerplate(
	child: DefaultTabController(
	length: tabs.length,
	child: TabBar(indicatorWeight: 0.0, tabs: tabs),
	),
	),
	);