Define and enforce Material dependency boundaries in Mix and mix_chart

## Use case

Downstream design systems need to know whether Mix packages are directly or transitively dependent on Flutter Material. Today that boundary is implicit.

On `main` at `c72802795b932191946a96a59f46ad320b3f66b1`:

- `packages/mix_chart/lib` has four direct `package:flutter/material.dart` imports in its [`fl_chart` backend](https://github.com/conceptadev/mix/tree/c72802795b932191946a96a59f46ad320b3f66b1/packages/mix_chart/lib/src/backend/fl_chart). The Material-specific values used there are `Colors.white` and `Colors.transparent`; the remaining types are lower-level Flutter primitives.
- Mix already exposes exact framework-neutral equivalents as [`MixColors.white` and `MixColors.transparent`](https://github.com/conceptadev/mix/blob/c72802795b932191946a96a59f46ad320b3f66b1/packages/mix/lib/src/theme/mix_colors.dart#L16-L18), and `mix_chart` already depends on `mix`.
- `packages/mix/lib` has 25 direct Material imports. Some are likely import-surface cleanup, but core also contains genuine Material integration through [`MixScope.withMaterial`](https://github.com/conceptadev/mix/blob/c72802795b932191946a96a59f46ad320b3f66b1/packages/mix/lib/src/theme/mix_theme.dart#L67), [`MaterialTokens`](https://github.com/conceptadev/mix/blob/c72802795b932191946a96a59f46ad320b3f66b1/packages/mix/lib/src/theme/material/material_tokens.dart), and `Theme.of(context)`.
- `mix_chart` depends on `fl_chart`, which currently has its own Material usage. Removing Mix-owned imports therefore establishes a direct-source boundary, not strict transitive independence.

This matters immediately to [conceptadev/remix#134](https://github.com/conceptadev/remix/pull/134), which removes Material from Remix-owned published source but still resolves Mix through the package graph.

## Proposal

Handle the work in explicit stages.

### 1. Remove direct Material usage from `mix_chart`

- Replace the four broad Material imports with the narrow Flutter libraries that own the referenced primitives.
- Reuse `MixColors.white` and `MixColors.transparent`; do not introduce duplicate local literals for those canonical colors.
- Add a `WidgetsApp`-based chart smoke test.
- Add a source-level check preventing new direct Material imports in the agreed package scope.

### 2. Audit the Mix core boundary

For each current core import, classify it as:

- a primitive available from `widgets.dart`, `painting.dart`, `foundation.dart`, `services.dart`, or `dart:ui`; or
- intentional Material interoperability.

Replace only the first category mechanically. For `MixScope.withMaterial`, `MaterialTokens`, and other real integration points, document the compatibility surface and decide separately whether they remain in core, move behind an optional adapter/export, or require a future package split. Do not make that breaking API decision as part of the `mix_chart` cleanup.

### 3. Track transitive constraints honestly

- Record `fl_chart` as a known transitive Material dependency after the direct cleanup.
- Do not label `mix_chart` transitively Material-free until that dependency is removed, replaced, or isolated.
- Publish and communicate the first compatible releases so downstream packages can update constraints deliberately.

## Acceptance criteria

- [ ] The 25 Mix core imports are classified as primitive-only or intentional Material integration.
- [ ] `packages/mix_chart/lib` has no direct `package:flutter/material.dart` imports.
- [ ] `mix_chart` reuses `MixColors.white` and `MixColors.transparent` for the exact canonical values.
- [ ] Chart tests pass under `WidgetsApp` without relying on `MaterialApp`.
- [ ] CI prevents new direct Material imports in the package scopes declared clean.
- [ ] Documentation and validation messages distinguish direct-source independence from transitive dependency independence.
- [ ] The long-term home of Mix's real Material integration is captured in a separately approved implementation plan before any breaking move.
- [ ] Downstream Remix tracking links the release or follow-up work needed to tighten its own dependency boundary.

## Non-goals

- Removing or breaking `MixScope.withMaterial` in the first cleanup.
- Forking or replacing `fl_chart` before its actual Material requirements are evaluated.
- Claiming that eliminating broad imports alone makes the dependency graph Material-free.

Start in packages/mix_chart/lib/src/backend/fl_chart and inspect the four Material imports and their referenced primitives. Then audit the 25 imports under packages/mix/lib, including mix_theme.dart and material_tokens.dart, separating primitive-only imports from intentional integration. Done means the agreed direct-import checks and WidgetsApp chart smoke test pass, while transitive fl_chart usage and the remaining compatibility surface are documented.

Written by the indexing model from the issue text.