[DX] Define a release tagging + CHANGELOG update process for contributors

[gregemax]

Summary

CHANGELOG.md exists (15 KB) and is well-maintained, but there is no documented process for how and when it gets updated. Contributors don't know whether to update it in their PR or whether it's maintained by maintainers only.

There is also no git tag strategy — no v0.x.y tags in the repo, making it hard to reference a specific state in issues or bug reports.

What's needed

1. Document the CHANGELOG process in CONTRIBUTING.md

Add a section clarifying:

• Contributors should add an entry under ## Unreleased in their PR if their change is user-visible
• Entries follow Keep a Changelog format: Added / Changed / Fixed / Removed
• Maintainers cut releases by moving ## Unreleased to a version section and tagging

2. Create the first proper git tag

Tag the current state as v0.1.0-alpha with a release note summarising:

• Soroban escrow contract (30 tests, WASM build)
• Backend API (auth, jobs, contracts, milestones, escrow service, payments module)
• Frontend (landing page, testnet demo, payments UI, jobs browse)
• CI (lint, test, WASM build)

3. Add a GitHub Release

Create a GitHub release from the tag pointing to the relevant CHANGELOG section.

Acceptance criteria

• CHANGELOG process documented in CONTRIBUTING.md
• v0.1.0-alpha tag created
• GitHub Release published with a link to the CHANGELOG section

Effort

~30 minutes. Good for a maintainer to pick up.

[Talentgift24-ux]

📋 Grainlify Application

@Talentgift24-ux has applied to work on this issue as part of the Grainlify program.

i would love to work on this issues

---

Repo Maintainers: To accept this application, review their application or assign @Talentgift24-ux to this issue.