Rework koolbase_build_id asset handling so clean builds don't break

[kennedyowusu]

Summary

koolbase_build_id is declared as an asset in a consumer app's pubspec.yaml, but the file is gitignored and only produced during koolbase release. Any build from a clean state that doesn't go through the full release flow fails in Flutter's asset bundler with:

No file or variants found for asset: assets/koolbase_build_id

…before the build (or tests) even start. The asset is declared-but-absent.

This is a design smell: every consumer of the build has to know to create a placeholder first. It has already produced two separate workarounds for the same root cause (see below), and will keep producing more as new build contexts appear (fresh clones, flutter run, IDE builds, contributor machines).

Evidence: two stopgaps already exist for one root cause

1. CLI release path. koolbase release runs flutter clean, which deletes the gitignored asset; the inner build then fails before it can stamp the real build_id. Worked around by having the CLI recreate an empty placeholder after
   the clean.
2. CI / plain build path. A plain flutter test (or any build) from a fresh checkout has no asset present, so the bundler fails. Worked around in CI by a step that creates a placeholder before the build.

Both treat the symptom in the place it happens to hurt. Neither addresses why a declared asset is allowed to be absent at build time.

Proposed direction (pick one)

• Don't declare it as a hard pubspec asset. Have the SDK resolve the build_id at runtime in a way that tolerates the asset being absent, so a
  missing file is never a build-breaking condition.
• Generate it automatically before any build. Produce the file as part of a pub get / build hook so it always exists before Flutter's bundler runs, without any consumer action.
• Commit a non-ignored placeholder. Ship a committed placeholder file (value irrelevant) that the release flow stamps over with the real build_id, so a clean checkout already satisfies the bundler.

Goal / acceptance

• A clean checkout can run flutter build / flutter test / flutter run without any manual placeholder step.
• koolbase release still ends up with the correct stamped build_id.
• The CLI placeholder workaround and the CI placeholder step can both be removed once the root fix lands.

Notes

• Whichever direction is chosen, document the build_id lifecycle (who creates it, when it's stamped, what reads it) so the asset stops being implicit knowledge.