dpm release should be triggered by `VERSION` file change rather than git tag

# Problem Statement

We would like dpm releases to only run after a PR is raised and approved for 4 eyes auditability, and to ensure that releases are only run off `main` / `release-*` branch

Today the release is kicked off whenever you push a git tag, and anyone can push a git tag on any commit, without secondary approval, or assurance that the tagged commit is actually on `main` or `release-*` branch

## Solution Notes

We currently leverage GoReleaser to release the dpm binary.

Although GoReleaser itself cannot trigger releases from a file change—it only runs when you invoke it (typically via CI), and it expects a Git tag unless you explicitly override that behavior.

What we can do instead is:

• Detect changes to `VERSION` file in CI on main / release line branch
• Create a Git tag based on that file
• Run GoReleaser using that tag

EXTRA CREDIT: And if we want to be super-neurotic, we could try to use protected tags to ensure that only CI can add tags / labels to the repo

implement automated tagging and creation of github release

potentially of merge of PR which upticks a root `VERSION` file similar to how we version in other repos.

TODO -- look into possible trigger alternatives with goreleaser

Step 1 - change `VERSION` file then triggers a tag created and pushed to github
Step 2 - Pushing tagging triggers goreleaser to life to create and publish the artifact, and then also automatically create the github release
Step 3 - slack subscriptions to `releases` for this repo then slack out notification of availablity of new release in slack

Locate the CI workflow and GoReleaser configuration that currently respond to pushed tags, then inspect how the root VERSION file is handled. Implement the VERSION-change flow on main and release-* branches, including automated tag and GitHub release creation, and verify that GoReleaser publishes the artifact only after the tag is created.

Written by the indexing model from the issue text.