fix(build-flutter): accept a DART_DEFINE_FILE secret for build-time dart-defines

[taorepoara]

Problem

A calling workflow's with: block for a uses:-based job is evaluated in a restricted context that does not include secrets (only github, needs, strategy, matrix, inputs, vars). Any caller that tried to bake a secret into flutter-build-args via ${{ secrets.X }} inside with: fails at parse time with:

Unrecognized named-value: 'secrets'

and the whole workflow run fails immediately with 0 jobs executed — not a runtime failure.

This blocks any consumer (e.g. Ximiti) that needs to pass a secret value into a --dart-define at build time.

Fix

Add an optional DART_DEFINE_FILE secret input to build-flutter.yml, kept generic rather than tied to any one app's dart-define keys. Its content (JSON or .env format, per flutter build --help) is written to a temp file from the build step's own env: block (where the secrets context is available, since it's evaluated at the job/step level, not inside a caller's with:), then passed to flutter build via --dart-define-from-file:

env:
DART_DEFINE_FILE: ${{ secrets.DART_DEFINE_FILE }}

if [ -n"${DART_DEFINE_FILE}" ];then
dart_define_file="$(mktemp)"printf'%s'"${DART_DEFINE_FILE}">"${dart_define_file}"
BUILD_ARGS+=("--dart-define-from-file=${dart_define_file}")
fi

Callers pass the secret via the job's secrets: mapping (e.g. a .env-formatted secret with as many KEY=value dart-defines as needed) instead of building --dart-define=... strings themselves in with:.

Compatibility

Fully backward compatible: the new secret input is optional and defaults to unset, so existing callers are unaffected.