feat(ci): implement release-please for automated releases

[kriscoleman]

feat(ci): implement release-please for automated releases

Summary

This PR automates the EKCO release process using release-please. Instead of manually pushing Git tags to trigger releases, the new workflow opens release PRs based on conventional commits, creates GitHub releases automatically, and builds/pushes the Docker image without manual intervention.

Changes

• Added .github/workflows/release-please.yaml with two jobs:
  • release-please: Runs on every push to main, opens/updates release PRs using release-please-action@v4
  • build-and-push: Triggered only when a release is actually created, checks out the release tag, builds the Docker image with make docker-image, and pushes replicated/ekco:<tag> to DockerHub
• Added release-please-config.json — configures the root package with release-type: simple and package-name: ekco
• Added .release-please-manifest.json — seeded with the current version 0.28.13
• Updated README.md release documentation to describe the new automated flow and how manual tag pushes still work as a fallback

Design Decision

The Docker build is integrated directly into the release-please workflow rather than relying on the existing release.yaml being triggered by the new tag. This is necessary because GitHub Actions tags created by the default GITHUB_TOKEN do not trigger other workflows — it is a platform limitation to prevent recursive runs. The existing release.yaml is intentionally kept so manual tag pushes still function as a fallback.

UAT

1. Merge this PR to main
2. Merge a subsequent PR with a conventional commit (e.g., feat: something or fix: something)
3. Verify that the release-please workflow opens a release PR proposing the next version
4. Merge the release PR and verify:
   • A GitHub release and Git tag are created
   • The Docker image replicated/ekco:<tag> is built and pushed

[xavpaice]

Question on this:

• Do we really want to release every PR? Even if there are a bunch of Dependabot etc updates that could be grouped?
• Has this approach been discussed and agreed with the team that 'owns' this repo?

[kriscoleman]

Question on this:

* Do we really want to release every PR?  Even if there are a bunch of Dependabot etc updates that could be grouped?

* Has this approach been discussed and agreed with the team that 'owns' this repo?

1. release-please handles this nicely, it doesn't continuously release what's landed to your default branch, it instead maintains "Release PRs". They are kept up-to-date as additional work is merged. When you're ready to tag and trigger a release, simply merge the release PR.

2. I'll have a discussion with them!

[kriscoleman]

closing as a different direction is being considered.