Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/android-build.yml:
- Line 245: The manual trigger in the android build workflow is missing
workflow_dispatch inputs, so jobs like the build and publish steps will see
empty inputs.* values instead of the defaults used by workflow_call. Mirror the
existing workflow_call input definitions under workflow_dispatch.inputs in the
same workflow configuration so manual runs expose the same parameters and
defaults, and make sure the jobs that reference inputs.app-id,
inputs.version-prefix, inputs.play-track, and inputs.gradle-task continue to
receive valid values.

In @.github/workflows/flutter-android-build.yml:
- Line 208: The workflow_dispatch trigger in the flutter-android-build workflow
is missing inputs, so manual runs won’t populate values used by jobs like
app-id, flutter-version, version-prefix, and play-track. Add a
workflow_dispatch.inputs block that mirrors the existing workflow_call.inputs in
this workflow, or add a guard in the relevant job definitions to skip execution
when required inputs are empty.

In @.github/workflows/flutter-ios-build.yml:
- Line 187: The flutter iOS build workflow now supports workflow_dispatch, so
add a top-level permissions block to the workflow with least-privilege access
instead of relying on default token scopes. Update the workflow definition to
explicitly set the minimum needed permissions, using the existing job steps
(such as checkout and TestFlight upload) to confirm that read-only repository
access is sufficient.

In @.github/workflows/ios-build.yml:
- Line 306: The iOS workflow now supports manual dispatch, but it lacks an
explicit top-level permissions block and may inherit broader default token
access. Add a least-privilege permissions section to the workflow in
ios-build.yml, aligned with the workflow’s actual needs, and keep the change
near the workflow_dispatch configuration so the security intent is clear.

In @.github/workflows/next-cloudflare-worker.yaml:
- Around line 106-113: The workflow is missing the same input definitions under
workflow_dispatch.inputs that are already declared in workflow_call.inputs.
Mirror the full inputs block in the workflow_dispatch section, including
project_name, environment, cloudflare_api_token, and cloudflare_account_id, so
the reusable workflow and manual dispatch resolve the same values. Use the
existing workflow_call.inputs block as the source of truth and ensure the
dispatch trigger references the same input names throughout the deploy job and
concurrency key.

In @.github/workflows/reusable-service-cicd.yml:
- Line 495: The manual trigger is defined without any inputs, so
`workflow_dispatch` runs hit the `chart-name` validation with an empty value and
fail. Update the reusable workflow’s `workflow_dispatch` block to declare the
same required input(s) used by the validation, especially `chart-name`, or
remove the manual trigger if it is not intended. Keep the trigger and the
validation in sync so the workflow entrypoint can be used safely.

In @.github/workflows/vite-cloudflare-worker.yml:
- Around line 103-110: The manual trigger is missing the same inputs that
jobs.deploy already consumes, so workflow_dispatch should mirror the
workflow_call inputs. Add the full inputs block under workflow_dispatch using
the same names, types, defaults, and descriptions for project_name, environment,
route, and the other existing inputs so manual runs resolve inputs.* correctly.
Keep the definitions aligned with the current workflow_call.inputs section to
avoid empty-string deployments.

---

Outside diff comments:
In @.github/workflows/android-build.yml:
- Around line 250-258: The build workflow jobs are missing concurrency control,
so concurrent runs on the same ref can overlap and interfere with shared caches.
Add a concurrency block to both the build job and the release_with_environment
job in the Android workflow, matching the pattern already used in
flutter-android-build.yml; use the job names and ref-based grouping consistently
so only one run per ref proceeds at a time, with in-progress cancellation
enabled as appropriate.

In @.github/workflows/ios-build.yml:
- Line 311: Add a concurrency block to the build job in the iOS workflow so
overlapping runs are cancelled/serialized like in flutter-ios-build.yml. Update
the build job definition to include job-level concurrency, using the build job
identifier and a workflow-specific group key so manual workflow_dispatch runs
don’t consume multiple macOS runners at once.