[antoinetoussaint-byte]

Closes #17.

Summary

• Follows this repo's release convention: each v0.0.X tag sits on a release: v0.0.X commit that bumps agent.codefly.yaml's version (see release: v0.0.16 with downloadable agents #11, release: v0.0.15 #10, release: v0.0.14 #8). This PR bumps 0.0.16 → 0.0.17 so the tag can be cut on a version-consistent commit.
• The linux/arm64 goreleaser build landed on main (feat: add linux/arm64 build (#14) #15) but the asset isn't published until a tag is pushed — the release workflow runs goreleaser-cross on push: tags: v*. Cutting v0.0.17 publishes service-swift_0.0.17_linux_arm64.tar.gz alongside the existing darwin/linux amd64+arm64 archives.

Post-merge step (required to publish the asset)

This PR alone does not publish the release. After merge, tag the release commit to trigger goreleaser:

gh release create v0.0.17 --repo codefly-dev/service-swift --generate-notes --target main

Then verify the arm64 asset:

gh release view v0.0.17 --repo codefly-dev/service-swift --json assets \
  --jq '[.assets[].name | select(contains("linux_arm64"))]'
# expected: ["service-swift_0.0.17_linux_arm64.tar.gz"]

I've left the tag/release to a maintainer since publishing a GitHub release is outward-facing and must land on the merged commit.

Test plan

• go build ./...
• go vet ./...
• go test ./... (boundary + manifest conformance pass with the bumped version)
• After merge: tag v0.0.17; confirm goreleaser publishes service-swift_0.0.17_linux_arm64.tar.gz