[material_ui] Allow custom MaterialInkController implementations

[Sanaullah49]

Removes the private _RenderInkFeatures cast from InkFeature so custom MaterialInkController implementations no longer throw a TypeError.

Also adds MaterialInkController.removeInkFeature, and paints ink via the enclosing Material ink render object when the controller itself is not a RenderObject (delegating controllers).

Fixes flutter/flutter#192060

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 enables custom MaterialInkController implementations by exposing removeInkFeature on the interface and removing private type casts in InkFeature. Feedback highlights that the current implementation's assertions and early-return checks in _paint will prevent custom delegating controllers from functioning correctly, and suggests relaxing the assertion and walking the render tree to find the correct paint context.

[gemini-code-assist]

The assert assert(identical(feature.controller, this)) will fail if a custom delegating controller delegates addInkFeature to the host _RenderInkFeatures. Since _RenderInkFeatures is a private class, any custom controller that actually wants to paint ink features must delegate to the host. To support this, we should relax the assert to allow custom controllers that are not RenderObjects.

    assert(feature.controller is! RenderObject || identical(feature.controller, this));

[Sanaullah49]

Updated: the assert now allows non-RenderObject controllers that delegate addInkFeature to the host Material.

[gemini-code-assist]

If a custom delegating controller is used, controller is! RenderObject will be true, causing _paint to return early and preventing any ink features from painting. To support custom delegating controllers, we can walk up the render tree from referenceBox to find the actual _RenderInkFeatures ancestor when the controller is not a RenderObject.

    RenderObject? paintContext;
    if (controller is RenderObject) {
      paintContext = controller as RenderObject;
    } else {
      RenderObject? ancestor = referenceBox.parent;
      while (ancestor != null && ancestor is! _RenderInkFeatures) {
        ancestor = ancestor.parent;
      }
      paintContext = ancestor;
    }
    if (paintContext == null) {
      return;
    }

[Sanaullah49]

Updated: when the controller is not a RenderObject, _paint walks from referenceBox to the enclosing Material ink render object. Added a paint regression test for a delegating controller.