fix(mix_generator): accept visible typedefs whose expansion names hidden types

[leoafarias]

Related issue

Not linked to an open issue.

Description

Splits the one behavioural change to a published package out of #1056, where it currently rides along with a new experimental package.

firstInvisibleTypeName decides whether a type can be named from the library being generated into. For a type alias it recursed into the alias's expansion, so a typedef the annotated library can see was still rejected whenever the aliased declaration mentioned a type that library does not import.

Generated code only ever writes the alias name, never its expansion, so the expansion's own types do not need to be visible. Returning null for a visible alias is what typeCode already assumes — it emits VisibleCallback, not the expanded function type.

The user-visible symptom: a spec whose field type is a visible callback typedef over a hidden type fails generation with a spurious visibility error.

Changes

• packages/mix_generator/lib/src/core/helpers/library_scope.dart — return null once the alias itself is visible, instead of falling through to the expansion walk. Four lines, one of them a comment.
• packages/mix_generator/test/core/helpers/library_scope_test.dart — regression test. visible.dart gains typedef VisibleCallback = void Function(HiddenType value); and hidden.dart a function returning it, so the fixture reproduces the exact shape: a visible alias whose expansion names a hidden type.

Verification

Check	Result
mix_generator tests	379 pass
dart analyze	No issues found
dart format --set-exit-if-changed	58 files, 0 changed

The regression test was confirmed to be real, not just additive. Reverting only library_scope.dart and re-running it fails as expected:

firstInvisibleTypeName accepts a visible alias whose expansion names hidden types [E]
  Expected: null
    Actual: 'HiddenType'

Why separate

This is a bug fix in a package that ships to pub, and it is the prerequisite that lets #1056's specs generate at all. Reviewing and releasing it on its own means the fix is not gated on decisions about an experimental package's API surface, and it gets its own mix_generator changelog entry rather than being folded into a mix_markdown one.

The patch is byte-identical to the one on claude/package-setup-simplify-3kwvvm, so once this lands, rebasing #1056 drops the duplicate commit automatically.

Review Checklist

• Testing: Have you tested your changes, including unit tests and integration tests for affected code?
• Breaking Changes: Does this change introduce breaking changes affecting existing code or users? — No. It only widens what the generator accepts; nothing that generated before stops generating.
• Documentation Updates: Are all relevant documentation files updated? — Not applicable; internal helper, no documented behaviour.
• Website Updates: Is the website containing the updates you make on documentation? — Not applicable.