`Build native` runs as part of the release workflow

The @appland/appmap release flow works roughly as follows:

• New commits land on main and release begins via https://github.com/getappmap/appmap-js/blob/main/.github/workflows/main.yml#L227-L228
• Semantic release runs, thereby:
  • Updating the version number in package.json
  • Updates CHANGELOG
  • Commits the above, where the commit message does not include [skip ci] for the following steps
  • The commit is pushed to main and a tag for the release is created at this commit
  • The new version is pushed to NPM, where the tag is next instead of latest, so end-users won't pick up the changes.
• build-native.yml is triggered via the newly pushed tag (https://github.com/getappmap/appmap-js/blob/main/.github/workflows/build-native.yml#L6-L7)
• The project is built on platform-specific runners and binaries are appended to a GitHub Release associated with the tag
• Once all binaries are published, a final step, finalize release updates the tag on NPM to latest, thereby triggering code editor users to pick up the new binaries.

Ideally the build native workflow would run as part of the regular release workflow on commit to main, instead of waiting for a tag push. It feels really fragile having the process split into two separate workflows across two distinct commits.

Read .github/workflows/main.yml at the release steps around lines 227-228 and .github/workflows/build-native.yml, including its tag trigger and finalize release step around line 259. Trace how the release commit, tag, platform builds, GitHub Release assets, and NPM tag promotion currently connect; done means the native build runs within the regular release flow with the final NPM promotion still occurring after all binaries are published.